🐧 Lunix


  • BINNED

    @blakeyrat said:

    Ok; but again: what's stopping them?

    If that was an easy question it would probably already be answered, a solution devised, and we'd laugh about stuff in this thread as a thing those poor wretches in the past had to do.

    My personal take? The diversity that exists in the Linux ecosystem is both a blessing and a curse. On one hand, you have a choice of tools, if you're unhappy with one you can seek out another. On the other hand there are so many competing "standards" that picking one over the other is nearly impossible, especially in a community where, due to the nature of open source, everyone has a say. Sure, some voices are more important than the others, but still.

    Now take PowerShell. If you worked at Microsoft and were asked to build it, right now (in this hypothetical I'm assuming it doesn't exist yet), what would you do? Well, it's a shell for an MS OS, built for power users and programmers who use that OS. What will you pick as a basis of your syntax and workflow? How many MS supported scripting languages you can pick from? 3? JScript, VBScript and .NET family (I am not differentiating between C# and VB in this case), correct? Is it a hard choice, really?

    Now try to do that as a Linux OS developer. Pick one. There's Ruby, there's Python, there's Perl, there's fuck knows whatever else. Then try not to lose your community in the process as well. Remember, no matter how big Debian or RHEL are they still depend on a community that contributes to the project. MS has enough paid programmers, and enough users that will stick with their OS either way that they don't have to worry about that. Linux distros usually don't have such luxury.

    Yes, it's excuses. No, I don't think that should stop them. But that's the current situation. Hopefully it will get better one day. For now, I can live with bash for basic day-to-day operations and script stuff in something else when going gets tough in bash. And I'll be the first one to throw it in /dev/null the day something better becomes the standard. But for now, bash is ubiquitous and I'll stick to that for scripting because I know it will work on 99.99% of Linux systems I want to use it on.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    A.k.a. "it's always been done that way." The absolute worst reason for anything.

    It's usually expressed in terms of “We don't want to break existing code.” The more foundational the code in question is (and operating systems are foundational by design) the more that matters, because giving the shaft to everyone who's built stuff on top of your code is a good way to make them angry jump ship to a competitor.


  • FoxDev

    @blakeyrat said:

    Right; and what's stopping the Linux community from replicating that? What's their excuse for having such an old, stupid, clearly wrong system still?

    Arrogance and stubbornness, most likely.



  • @dkf said:

    It's usually expressed in terms of “We don't want to break existing code.”

    Yeah but as we're discussing, their "existing code" is a delicate nightmare of buggy edge-cases and unspoken assumptions. (Assumptions like, "a filename won't have a carriage return in it".)

    Breaking it sounds like a PRETTY FUCKING GOOD IDEA to me.



  • @blakeyrat said:

    You are double-shitting here. Your company is full of people doing dumb and wrong things, then telling other people the dumb and wrong things are the "best practice" and I hate you.

    Hey, don't shoot the messenger! I don't work there any more!



  • @Onyx said:

    But for now, bash is ubiquitous and I'll stick to that for scripting because I know it will work on 99.99% of Linux systems I want to use it on.

    That's another thing. It's not uncommon these days to get a brand new server with something like Centos 5, which is locked to 7-8 years old technology. Add to that thousands of servers with even older tech, that have fallen out of update cycle entirely.

    Any technology you replace in the ecosystem will have to go through a decade long process of assimilation, as all these servers slowly, painfully, switch over while keeping the world's IT infrastructure chugging along. You better have a damn good compatibility layer in place.



  • @cartman82 said:

    You better have a damn good compatibility layer in place.

    Why have any compatibility layer? Just have BOTH CLIs present on the machine, and have a policy from the OS or distro (or whatever) saying "no check-in of new Bash scripts will be accepted."

    EDIT: oh wait, lemme guess, Linux is also so fucking stupidly designed that it can have only one CLI interface at any given time, right?


  • BINNED

    @blakeyrat said:

    oh wait, lemme guess, Linux is also so fucking stupidly designed that it can have only one CLI interface at any given time, right?

    Oh, it's doable. The problem is, once again, defaults. For example, on this install I unchecked the "Desktop environment" package during install, rebooted to shell, and installed what is considered a non-standard Desktop environment for Debian. Because I know how to do that shit. You'd be the first one to call that a usability problem, because I had to fuck around with arcane incantations in CLI to get a desktop running.

    If that's something I'd have to do for my default shell because I don't like the one I got by default, that would also be a usability problem.

    Hence, compatibility layers. I also didn't get pissed at systemd either. You know why? Because stuff like service <servicename> <action> still works, even though systemd uses `systemctl <action> <servicename>``. That means my own scripts aren't broken due to a good compatibility layer.

    And yes, it is possible to indicate which shell your script uses. But do you really believe that will help after all the rants you had about Windows applications putting files in the wrong directory? Same shit happens this side of the fence, too.



  • @Onyx said:

    You'd be the first one to call that a usability problem, because I had to fuck around with arcane incantations in CLI to get a desktop running.

    Yeah, so they should fix it so you don't. Duh.

    @Onyx said:

    If that's something I'd have to do for my default shell because I don't like the one I got by default, that would also be a usability problem.

    Right; they should fix that too.

    @Onyx said:

    And yes, it is possible to indicate which shell your script uses. But do you really believe that will help after all the rants you had about Windows applications putting files in the wrong directory? Same shit happens this side of the fence, too.

    So developers are bad, therefore OS makers shouldn't even fucking TRY to ship a quality product?

    Compelling argument.



  • I am compelled to leave this here for reasons...

    God damnit open sores stealing all Windows innovations!


  • BINNED

    @blakeyrat said:

    Yeah, so they should fix it so you don't. Duh.

    I'm a special snowflake who wanted to run Cinnamon on Debian which is not the official way it's distributed. What would you do? Offer me a huge list of DEs I may not care about or even know what they are (assuming I wasn't someone familiar with all that shit). Default is Next-Next-Finish-Gnome. That won't break a thing. I'll get a desktop. I may not like it, but it will work. Changing the shell might be a bit trickier, because, you know, all those scripts that use it.

    @blakeyrat said:

    Right; they should fix that too.

    With a compatibility layer like @cartman82 said. What are we arguing about then? Or do you have a better proposition?

    @blakeyrat said:

    So developers are bad, therefore OS makers shouldn't even fucking TRY to ship a quality product?

    Nobody said that. All we want is a compatibility layer that will take care of that and nobody gets hurt. Win-win.

    @blakeyrat said:

    Compelling argument.

    Thanks, I'm trying.



  • @blakeyrat said:

    Why have any compatibility layer? Just have BOTH CLIs present on the machine, and have a policy from the OS or distro (or whatever) saying "no check-in of new Bash scripts will be accepted."

    Who's gonna rewrite all the legacy battle-tested bash code floating around? Especially when the people supposed to do it don't think there's anything wrong with bash? They'll just keep everything chugging along inside bash and ignore the new thing altogether.

    If there's any chance of evolving, it'd be a new shell with compatibility fallback mode. But bash is so finicky and baroque at this point, any compatibility layer will compromise the new thing as well.

    So fat chance of anything replacing the nix shell in the foreseeable future.



  • @cartman82 said:

    Who's gonna rewrite all the legacy battle-tested bash code floating around?

    Well they either PAY people to do this work, or people who give a shit about Linux not sucking. (Which is none.) So basically Linux sucks forever. Yay! Let's pick it for our products! The OS that sucks forever, great choice!!!



  • @blakeyrat said:

    Yeah but as we're discussing, their "existing code" is a delicate nightmare of buggy edge-cases and unspoken assumptions. (Assumptions like, "a filename won't have a carriage return in it".)

    Breaking it sounds like a PRETTY FUCKING GOOD IDEA to me.

    On Sun, Dec 23, 2012 at 6:08 AM, Mauro Carvalho Chehab
    mchehab@redhat.com wrote:

    Are you saying that pulseaudio is entering on some weird loop if the
    returned value is not -EINVAL? That seems a bug at pulseaudio.

    Mauro, SHUT THE FUCK UP!

    It's a bug alright - in the kernel. How long have you been a
    maintainer? And you still haven't learnt the first rule of kernel
    maintenance?

    If a change results in user programs breaking, it's a bug in the
    kernel. We never EVER blame the user programs. How hard can this be to
    understand?

    To make matters worse, commit f0ed2ce840b3 is clearly total and utter
    CRAP even if it didn't break applications. ENOENT is not a valid error
    return from an ioctl. Never has been, never will be. ENOENT means "No
    such file and directory", and is for path operations. ioctl's are done
    on files that have already been opened, there's no way in hell that
    ENOENT would ever be valid.

    So, on a first glance, this doesn't sound like a regression,
    but, instead, it looks tha pulseaudio/tumbleweed has some serious
    bugs and/or regressions.

    Shut up, Mauro. And I don't ever want to hear that kind of obvious
    garbage and idiocy from a kernel maintainer again. Seriously.

    I'd wait for Rafael's patch to go through you, but I have another
    error report in my mailbox of all KDE media applications being broken
    by v3.8-rc1, and I bet it's the same kernel bug. And you've shown
    yourself to not be competent in this issue, so I'll apply it directly
    and immediately myself.

    WE DO NOT BREAK USERSPACE!

    Seriously. How hard is this rule to understand? We particularly don't
    break user space with TOTAL CRAP. I'm angry, because your whole email
    was so horribly wrong, and the patch that broke things was so
    obviously crap. The whole patch is incredibly broken shit. It adds an
    insane error code (ENOENT), and then because it's so insane, it adds a
    few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").

    The fact that you then try to make excuses for breaking user space,
    and blaming some external program that used to work, is just
    shameful. It's not how we work.

    Fix your f*cking "compliance tool", because it is obviously broken.
    And fix your approach to kernel programming.

               Linus
    

    note that userspace breaks userspace all the time, but all the kernel devs can do is complain

    click the lkml.org link for context



  • This one was also entertaining....

    The response is:

    "Generic terms are generic, not the first user owns them."

    And by "their" you mean Kay Sievers.

    Key, I'm f*cking tired of the fact that you don't fix problems in the
    code you write, so that the kernel then has to work around the
    problems you cause.

    Greg - just for your information, I will not be merging any code
    from Kay into the kernel until this constant pattern is fixed.

    This has been going on for years, and doesn't seem to be getting any
    better. This is relevant to you because I have seen you talk about the
    kdbus patches, and this is a heads-up that you need to keep them
    separate from other work. Let distributions merge it as they need to
    and maybe we can merge it once it has been proven to be stable by
    whatever distro that was willing to play games with the developers.

    But I'm not willing to merge something where the maintainer is known
    to not care about bugs and regressions and then forces people in other
    projects to fix their project. Because I am not willing to take
    patches from people who don't clean up after their problems, and don't
    admit that it's their problem to fix.

    Kay - one more time: you caused the problem, you need to fix it. None
    of this "I can do whatever I want, others have to clean up after me"
    crap.


  • BINNED

    @Onyx said:

    PowerShell has the advantage of being made by Microsoft, using Microsoft's languages, for Microsoft's operating systems.

    and for other Microsoft applications.

    One of it's pro points is that it is rather easy to do AD, Exchange, SharePoint, MS SQL stuff with it.


  • Discourse touched me in a no-no place

    @swayde said:

    This is probably the bug i hit most om Windows.

    You sound like Blakey, calling that a bug. Just because you don't like how it works doesn't make it a bug.



  • It's a bug because the filesystem supports 32000 byte filenames and the OS API only supports it on half of its functions. And the Windows GUI uses the half that doesn't for some indiscernible reason.


  • FoxDev

    @ben_lubar said:

    It's a bug because the filesystem supports 32000 byte filenames

    NTFS might, but FAT32 certainly does not. Unfortunately, MS still need to support it.



  • If Linux can handle having different types of filesystems in the same directory tree, I don't see why Windows has so much trouble having them in separate directory trees.



  • @ben_lubar said:

    It's a bug because the filesystem supports 32000 byte filenames

    UH ACTUALLLLLLLLY!!!

    The maximum length of a filename is 255 characters.

    The maximum length of a path is 32000 characters.



  • Different types of filesystems is some kind of socialist plot to undermine the purity of our essences, amirite?



  • Why can't there be a filesystem where filenames are arbitrary strings and paths are separated by having multiple strings in an array?



  • @ben_lubar said:

    Why can't there be a filesystem where filenames are arbitrary strings and paths are separated by having multiple strings in an array?

    Sure, why not?



  • You are correct. I'd vastly prefer they enabled long paths as default tho. Then buggy software would be "forced " to get fixed.
    To paraphrase blakey: no program should ever refer to a file by something other than an inode.



  • Because the OS API for every OS uses strings to represent a whole path.



  • @ben_lubar said:

    Because the OS API for every OS uses strings to represent a whole path.

    OH SNAP I GOT TRICKED BY BEN L!


  • area_pol

    This thread has potential.


  • Discourse touched me in a no-no place

    @swayde said:

    To paraphrase blakey: no program should ever refer to a file by something other than an inode.

    Yet users users continue to want to use readable names for everything!

    <FX:tuts-and-sighs>

    Users, eh?


  • FoxDev

    @ben_lubar said:

    If Linux can handle having different types of filesystems in the same directory tree, I don't see why Windows has so much trouble having them in separate directory trees.

    It doesn't; the Explorer shell has issues. And that's only because it's not been deemed important enough to deal with them.



  • If you were designing the first ever operating system that everything will be based on, but you have the knowledge of how operating systems are right now, how would you design things like strings and file paths and argument passing?



  • @dkf said:

    Yet users users continue to want to use readable names for everything!

    <small><FX:tuts-and-sighs></small>

    Users, eh?

    What do you mean,    .txt and        .txt are different files?



  • Programs! =users.
    I thought of adding that, but decided against it. I thought it was obvious .


  • FoxDev

    @ben_lubar said:

    If you were designing the first ever operating system that everything will be based on, but you have the knowledge of how operating systems are right now, how would you design things like strings and file paths and argument passing?

    Strings? .NET's implementation is pretty good, so I'd do something like that.
    File paths? I see no practical reason to have a length limit, though for technical reasons, I'd still apply something. But it'd be a really big number. Like 4,294,967,295.
    Argument passing? Tricky. Ideally, I'd want the user to define a data structure to pass as an object, but that might make the CLI too hard to use. But having a space-separated string is not good either.



  • Seen the limits for ZFS? I quite like those...


  • FoxDev

    The filename length is a bit on the short side though, no? 😄



  • Yeah, tho I hardly ever run info filename length - it's always path length...
    (autocorrect)



  • I tried to install a ZFS filesystem when I was trying to get FreeBSD 10 on my MacBook. It... didn't work. It worked even less than FreeBSD 10 on UFS...



  • I have it running under freenas and openindiana. Works flawlessly here. It's a bitch to configure if you want acl's etc..
    Edit: zfs->freenas



  • It's probably a case of hardware configuration vs patience. I am planning on giving FreeBSD 10 another shot in the future (I got my wife to technically approve me buying a new laptop based on conditions), so I'll probably find some nice BSD Hardware and give it a shot on that...


  • Java Dev

    @RaceProUK said:

    Argument passing? Tricky. Ideally, I'd want the user to define a data structure to pass as an object, but that might make the CLI too hard to use. But having a space-separated string is not good either.

    Objects may still be the way to go. You'd just be required to use shell builtin functions or external programs to create them. Something like this could work:

    rm (list (glob ./*.txt) ./README)
    


  • EVERYTHING IS DATAJSON



  • rm ls (gl ./*.txt) ./README

    You just know that they would abbreviate as much as possible.



  • @Eldelshell said:

    Bash? Maybe ksh handles piping differently
    The contents of the pipe are set by the program; the shell has nothing to do with it.

    @Eldelshell said:

    find/xargs are just applications present in any *nix. And usually, when you find them together is a hack... Your doing it wrong™
    And yet there are probably more examples of doing it wrong than there are of doing it right if you look around. And surprise surprise, not all filenames are produced by find or consumed by xargs, and there sometimes isn't a way to do it right.

    @Eldelshell said:

    or 30 years, using spaces in filenames has been a bad idea in *nix systems. That you don't know already to workaround those is another reason to stay away.
    Ah yes, the "let's change our behavior to conform to a crappy system" viewpoint.

    @anonymous234 said:

    And yet, nobody in the Linux world has any intention to develop a replacement for the shell.
    I am, in fact, a nobody in the Linux world, but I am a heavy Linux user and buy into a lot of the Unix philosophy, though not all of it.

    I would love to write a replacement (i) shell and (ii) "terminal emulator" and (iii) set of replacement utilities (for some of coreutils and such). I have a pretty clear picture of what I want, and actually started working on (iii) a while back, but I have way more things that I would like to do than I actually have time and motivation to actually do.



  • It's remarkably often that the shitty tool that exists right now wins out over the perfect tool which could hypothetically exist in the future...


  • Discourse touched me in a no-no place

    @EvanED said:

    I would love to write a replacement (i) shell and (ii) "terminal emulator" and (iii) set of replacement utilities (for some of coreutils and such). I have a pretty clear picture of what I want, and actually started working on (iii) a while back, but I have way more things that I would like to do than I actually have time and motivation to actually do.

    The utilities are an awkward place to start. There's a lot of them, so you end up spending a lot of time switching between them just tinkering with things other than your real goal (such as ensuring that everything will build right once you start changing stuff). Making a shell or terminal is a more focussed project.

    The core of a shell is pretty simple: it runs subprocesses in ways according to what you type in, and it lets you connect subprocesses together. There's a bit more to it than that, but that's the essential part.

    Terminals (well, terminal emulators; a real terminal is something like a VT100 and you build those with a soldering iron) are more complex. They're GUI code (so lots of bonus complexity right there), and they also delve in rather deeply into the more mysterious parts of how OSes work. I don't know if it's even possible for someone other than Microsoft to write a full one for Windows, and doing so on any of the Unixes requires understanding what is really going on with the tty/pty device system. And you probably have to emulate an existing terminal for things to work as you expect: there's a lot of code with embedded code to generate extended-VT100 sequences (usually following the xterm+color model) that do a whole bunch of things that are really quite neat.

    So I advise writing a shell. Then trying to use it; you don't want to inflict obviously-misanthropic usability nightmares on other people if you can catch them trivially by self-testing. It'll still be easier than rewriting all the utilities or a terminal emulator, both of which are huge tasks for different reasons.



  • @dkf said:

    The utilities are an awkward place to start. There's a lot of them, so you end up spending a lot of time switching between them just tinkering with things other than your real goal (such as ensuring that everything will build right once you start changing stuff). Making a shell or terminal is a more focussed project.
    The flip side is it's really quick to start; e.g. you can get a replacement for ls going much faster than a usable shell. (That's probably true even after I wrote and then rewrote a better library for getting directory listings than you get with Python (my host language because it's good at rapid prototyping and for playing around with things as I say "oh I want that instead"). I should put that up on PyPi...) Then you can add on additional utilities as you find need, and in the meantime fall back to existing utilities if you don't have something to support. There's actually not even all that many programs that need to be changed for what I want.

    In contrast, if you're like "oh I wish my shell had a for loop" now all of a sudden you have to switch shells, which means you lose your command history and stuff. And getting off the ground, unless you want to rewrite a fair bit later, means writing a significant proportion of the parser before you'll have anything remotely usable. On top of that, I think I probably use more shell features regularly (including some fairly obscure stuff like ^foo^bar and !!:gs/foo/bar to rerun the previous command with foo->bar replacements) than I do "advanced" utilities or stuff like that.

    Finally, despite saying I have a pretty clear picture of what I want, one thing I actually don't have that good a view of is a division between shell and terminal, as I anticipate those being a lot more connected than they traditionally are.

    @dkf said:

    And you probably have to emulate an existing terminal for things to work as you expect: there's a lot of code with embedded code to generate extended-VT100 sequences (usually following the xterm+color model) that do a whole bunch of things that are really quite neat.
    These are things that I'm not actually sure how to deal with, because my vision is not a matrix of characters and it's really unclear if it can be made to even emulate that. I don't have a good plan for that either; probably I'll just revert to saying that things that get much more complicated than color codes have to be run in an existing terminal.

    (FWIW, I actually kinda started on the terminal as well. :-) The display is Webkit, if that gives you an idea of having something that's very different.)



  • I was actually thinking of JSON as the simplest way you could implement objects through Linux pipes...



  • Ah yes, the "let's change our behavior to conform to a crappy system" viewpoint

    Really? What a stupid comment. You're doing that every day you write a URL, when sending an email, when writing code and even by looking at a screen for 8 straight hours. And, my behavior is to never use spaces in file names.



  • I was thinking myself of using a Python module to replace the shell.

    Because Python is a decent language in itself, and is already found on most Linux systems. The problem is its file and process management functions are awkward as fuck. But what if you could do something like

    from shell import *
    
    for f in find("~/stuff", iname="*.txt")
        print("Deleting file "+f.name)
        rm(f)

Log in to reply