🐧 Lunix
-
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.
-
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
angryjump ship to a competitor.
-
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.
-
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.
-
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!
-
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.
-
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?
-
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 likeservice <servicename> <action>
still works, even thoughsystemd
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.
-
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.
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.
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!
-
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.
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?
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.
Compelling argument.
Thanks, I'm trying.
-
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.
-
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!!!
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
Because the OS API for every OS uses strings to represent a whole path.
OH SNAP I GOT TRICKED BY BEN L!
-
This thread has potential.
-
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?
-
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?
-
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 .
-
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...
-
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...
-
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.
-
Bash? Maybe ksh handles piping differently
The contents of the pipe are set by the program; the shell has nothing to do with it.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 byfind
or consumed byxargs
, and there sometimes isn't a way to do it right.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.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...
-
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.
-
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 forls
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 withfoo
->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.
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)