What the GNU?
ariadnavigo.xyz
ariadnavigo.xyz
The article raises interesting points, but the whole rant against GNU and FSF is weird. GNU (yes, and Linux) and FSF is why many of us are in this business. They played a huge role in the career and passions of many of us -- I feel entitled to say "us" just like the author of TFA carelessly speaks about "we" -- and misunderstanding the history of how we got there doesn't help.
To me it feels as if a new generation of tech minded people have started taking things for granted, "why do we even need all those movements fighting for users' freedom, if I am free now?". It's a bit depressing.
The different approaches and goals of Linus Torvalds and RMS are both valid, and only in hindsight can we say one triumphed and the other didn't, but the article makes it look as if one of the two was obviously wrongheaded.
So some interesting points, but it could do without the whole rant against GNU and the FSF, and without the accusations of cultishness.
But I think more generally, wrt FSF there's not so much controversy [1] as disappointment in the FSF failing to stay relevant. Copyleft was a solution to the 80/90'ies software world. The FSF tried with the AGPL to answer the 'threat' of SaaS, but largely the world has shunned it except as a poison pill license to upsell a proprietary version. Similarly with the GPLv3 the FSF tried to answer to the threat of Tivoization, but again, largely failed to gain adherents in the low level components, like the Linux kernel, where this would have mattered.
[1] Well, the FSF taking RMS back on its board did produce a tsunami of corporate (financial) contributors leaving ship.
It's odd because it's worded in a way that sounds as if the FSF wasn't necessary now (or maybe even never), instead of thinking that the FSF is needed more than ever, now that there's a war against general purpose computing and against privacy and users' rights, and that if the GPL3 and AGPL didn't work -- which is possible! -- then how do we fix that?
Instead it's either apathy and even scorn against the FSF, which is alarming to me.
It's not just FSF, there's also ethical software types trying to destroy OSI from within. We are seeing so many attempts to dismantle important organizations now it leaves me baffled.
Indeed. Most fundamentally, they take their computing freedom for granted. There are powerful forces who want to take it away from us. There are powerful and rich people out there who think it's too dangerous for mere citizens to have access to unrestricted computers.
People focus on Stallman's software licenses as if that's what he's all about. They barely matter. People ignore the big picture: computing freedom. It's not just important, it's fundamental. Without this freedom, there is no hacking as we know it. There is no way to write and run our own software. What good is free software if a corporation or government signature is required to run it?
Stallman saw this coming before most if not all of us.
To an extent, I agree. I wonder whether the general move in the open source community will turn out to be a Faustian bargain. Are open source developers just a bunch of suckers being taken advantage of to provide building blocks for various proprietary business models? OTOH I'm thinking that more open source code out there is a public good, and we should rejoice in that regardless of 'proprietary free riders'.
> People ignore the big picture: computing freedom. It's not just important, it's fundamental.
No. What's fundamental is freedom for people. Computing freedom matters only as a means to that end.
I agree, and I'm going to guess the person you're replying to also agrees. In fact, RMS would also agree. It's just that we are narrowly focusing on a single aspect of freedom in this conversation, but yes: freedom to live, to work, to education, to health, are all more important :)
Perhaps. The whole point of the GPL is to give free software developers advantages and create leverage we can use against those who would exploit our labor. Permissive licenses allow that exploitation.
In the end, it's irrelevant. All this software, all this positioning for advantages and leverage, none of it will matter if the machine itself is taken away from us.
We'll never be truly free until computer manufacturing is as democratized as software development. Ideally we should be able to make computers at home.
> No. What's fundamental is freedom for people.
Absolutely. Computing freedom is a subset of personal freedom.
If we had a few NGOs that were committed to freedom, were transparent and produced good hardware it would be a more reasonable option. Sure I can dream about the future where I can 3D print all electronics at home, but that computer wouldn't run very good and we all know this.
NGOs are still centralized operations that can easily be targeted and corrupted. We need decentralized manufacturing. Anyone should be able to make functioning computers and it should be impossible to stop or even regulate it.
> the future where I can 3D print all electronics at home, but that computer wouldn't run very good
It would be better than nothing. They may have relatively low performance but they would still be computers that are guaranteed to be free and completely under our control. The fact they exist at all would provide significant protections against attempts at controlling us.
End result was that countries would spend millions just to be able to share documents across agencies. Things started changing when KDE/Slackware, Ubuntu, Firefox, OpenOffice and other software systems started to become user-friendly, with nicer and intuitive interfaces. From this point on, governments started teaching GNU/Linux in schools and universities, explaining the benefits, the rights, etc, and then switching to open-sourced and free-software systems.
That's something the article leaves out: while GNU and Linux are many times seen as a unit, there's a rich history of installing the GNU tools on other Unixes, because of the extra functionality they offer.
There is, of course, the argument against portability. At my last job, as the only Linux user on my team, I more than once wrote shell scripts that only worked for me - as soon as someone on macOS ran them, they'd run into a missing feature on `sed`, or a different calling convention on `date`. Which is why, at my current job, I'm very begrudgingly a macOS user - it makes me a better coworker.
There are good reasons for many of those extensions. Many options implement capabilities that probably should be in the standard, but currently aren't. For example, POSIX doesn't have easy-to-use secure options for handling file names; attackers can insert newlines in filenames, yet POSIX lacks options like find -print0 and xargs -0, so you either spend a great deal of additional time writing complicated code that's likely to be insecure, or you simply use extensions as almost everyone actually does. Even the BSDs and busybox include those examples, by the way. Also, long option names are excellent for making scripts easier to understand, and really should be in the POSIX standard for systems that are not highly memory constrained.
I try to make my shell scripts portable when that is reasonable, but sometimes that is simply far too difficult. The minimalism of POSIX is an advantage on small systems, or in other constrained environments, but most of us today are not trying trying to write software for a PDP-7.
In most cases the scarcest resource is developer time. In that case having rich functionality and extensions that improve readability is more important. I think the market is being perfectly reasonable, minimalism is less important than developer efficiency in most cases. Your mileage may vary.
> OK, now have a look at the 120 lines long source of GNU yes. And compare now that behemoth against the implementation in OpenBSD, the one from sbase, or the one from busybox. Like… why does GNU yes does so many memory operations for a task that is implemented so easily by everyone else?
The answer can be seen here: https://news.ycombinator.com/item?id=14542938 https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
But from the style of the author, it is clear that it is the case of a knowledgeable well informed educated person. GNU clearly has its problems, but badmouthing it like that is hard to differ from malice.
[0]: https://www.gnu.org/prep/standards/standards.html#Reading-No...
I don't see why the standard for composable utilities should allow for inefficiency.
It's not a bad retort, it's the end of the story: there is a superior utility, it's implemented.
My position is: either articulate an argument for why it's bad for /usr/bin/yes to be implemented the way GNU yes is implemented or drop the argument entirely.
Your comments manage to be in disagreement with those on the other side of this, and yet still adopt an argumentative/defensive tone with respect to what I've written. I consider this to be an even bigger waste of time than the people (like OP) who are upset about GNU yes's implementation.
> as bad as the GNU advocates' retort ("GNU yes is 10GiB/s fast").
If you don't want to defend your position, don't take it.
(Are you under the impression that "X is at least as bad as Y" is the same thing as saying "Y is bad"—and that that means I need to defend the position that Y is bad? It doesn't. Maybe learn to read English better, especially before leaping so confidently into trying to argue with someone over what you're reading. Another bonus tip: not only is it important to read in complete sentences, but it's important to write in complete sentences, too, and to make sure that the sentences follow logically one after the other.)
But that is not why I commented. I commented because I wanted to illustrate that the author questioned something that can be easily answered with a simple google search. I'm sure the author is qualified enough to answer the question, but instead left in the post giving most readers a impression that the complexity is there out of incompetence of GNU developers.
EDIT: I should not assume you asked in bad faith, but as the sibling commented. The answer to your question can be easily found in the link I posted. Making your behavior strangely similar to the author of the post: making questions that can be easily answered while giving a bad impression of others. Please, avoid that. It may work in many places but will fire back at you sometimes.
(Skills are not the same as factual knowledge here.)
Maybe it is a sensible subject for me or I've been living with people asking rhetorical redundant questions as a passive agressive form for disqualifying others.
I read your question as: "I can't see any reason this performance is needed, maybe it is really incompetence or pedantism from GNU developers." But I think it is prejudice on my part.
Sorry.
EDIT: grammar.
Anyways, back to the original question, I do believe that a lot of programmers (I don't buy OP's separation between GNU and non-GNU) over-engineer things without regard to the costs created by over-engineered code. My default assumption is that that's happening in yes. If it's happening in such a small program where it's so obvious, the same tendencies are likely to be at work in more complex programs like cat and awk and cc. Happy to debate that :)
That whole thread makes me sad. Another, more subtle way IP is ruining the world. But that's neither here nor there on this debate.
Just to flesh out my current thinking a bit more:
* I'd really like a study to understand how much complexity old GNU tools have gained in the past 2 decades. Because that would not be due to copyright concerns. But I'm not sure I have the necessary skills. (I'd like this study for non-GNU as well, but I assume copyright is not a concern there so the study doesn't have to set crisp time bounds.)
* I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
You are welcome! Considering the karma I got from that answer, I don't think I'm the only one who misread you. If you want a piece of advice: starting a question like that with "Genuinely curious: ..." is my strategy to prevent this kind of misunderstanding.
> * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
As Drew DeVault's says, it was his code which was broken. I know glic code is complex, but it is battle tested, mature and highly robust. I'd bet there are good reasons for that complexity. If I was really curious as to why, I'd try asking devs directly to avoid making them look bad by making public statements about it.
Now, I looked in scdoc code. The solution was to cast the parameters to "unsigned char". Considering the code
uint32_t ch;
isalnum(ch);
EDIT: possible nice finding: https://news.ycombinator.com/item?id=24597461
EDIT2: part of the reason: "unsigned char" can't hold EOF.
Regarding "asking devs directly": I often find it challenging even to figure out where to ask. Going from a program to its package, dealing with interactions between packages, etc. All of which goes back to simplicity as a core goal. "Good reasons for complexity" isn't sufficient, IMO. Complexity requires having a place to explain the reasons, and making it easy for people to find the place. Considering that we're all volunteers when it comes to open source and this sort of documentation is difficult, I'd often rather err on the side of not having a feature rather than having a more complex feature.
On the other hand, there are fields like internationalization or power management on laptops that are irreducibly complex. Not sure where I'm going with all this. Open source today serves businesses more than people, IMO. But it also serves people indirectly through businesses. This is a difficult topic. Your comment made it seem like there's an easy thing Drew or I could do. I'm not sure that's the case.
I also think internationalization is important, and that ASCII is mostly good at disempowering others. But at the same time I hate the way C locales work. They're a ridiculously terrible way of dealing with the problem, and an endless source of bugs.
And for that matter, what should `isalnum(六)` return? (in case HN mangles that, I put the Japanese "Roku" kanji there, i.e. the numeral 5). I'd say it should return `true` no matter what locale you're set to, since it's a numeral. But glibc returns `false` unless your locale is set to Japanese when `isalnum` is called, and musl returns `false` always. Yet they inconsistently return `true` for `isalnum(5)`, no matter the locale.
Case in point is that most people have no idea of how POSIX defines "text file" (ie. ends with \n, no line is longer than LINE_MAX), and what happens when you inout something that technically is not text file into POSIX utility that expects text file is undefined. GNU tools do something sensible or at least produce an meaningful error message, traditional Unix userspace usually does not (lines get truncated, last line sillently ignored, some buffer somewhere overflows and in better case you get SIGSEGV...).
But `yes` isn't such a thing, it's a standalone tool. Here the UNIX philosophy "Write programs that do one thing and do it well" comes rather at play.
Further, the optimizations it makes are not really complicated nor expensive to maintain. A page aligned buffer twice the most common page size is standard for basically everything where something is written or memory moves around.
One certainly can argue that it is Ok doing it more simply as it still is more than fast enough for the common use case. But arguing that a bread and butter optimization, namely one that adds just a few dozen lines of code total while increase throughput by three orders of magnitudes, should not be made, or that it even points to a complexity problem, is not holding any ground IMO.
Who is this 'we'? I don't care about the UNIX philosophy (I'm an emacs user). First thing I do on bsd systems is install the GNU userland. BSD tools follow the POSIX spec like a cult refusing to add useful extensions. Look how hopelessly broken posix sh is. I work quite often with busybox on small embedded systems and the limitedness of its vi implementation makes me irrationally angry.
Be wary of posts and articles which talk about an universal "we" as if everyone thought the same.
I, for example, care more about the philosophical aims of the FSF and RMS than about the finer technical points. That Linux is a very useful OS for me is a bonus. So "we" do not just care about tech; "we" also care about users rights and freedom.
> And we like things following the standards already put in place. Because we don’t give a damn about helping the FSF do their thing: We care about tech. We care about and love the legacy of UNIX, its philosophy, and we want to adhere to it as strictly as possible.
Sorry for breaking it up to you, but this kind of "standards must be respected 11!!!!1&!1" mindset is the actual cult-like behaviour, commonly found in communities such as cat-v.org, and with people clinging to plan 9 like it's anything beyond a failed experiment.
GNU and shells like bash (I use zsh which is I guess even "worse" in terms of feature bloat) are dominant because they provides a ton of super useful features to make work faster. Likewise you bash against glibc's bloat, but most software perform faster when using glibc than other "less bloated" libc implementations like musl ; the bloat is here for a reason and that reason is performance (which matters infinitely more than whatever ideological purity BS someone can find). Who cares if it's not strictly POSIX compliant: it makes computing a better experience and that's all that matters, and if tomorrow someone manages to create an entirely different non-posix platform that manages to improve on that, I'll happily jump there and I hope you do too.
I had assumed that this was about shell script portability. Bash and zsh have a ton of super useful features to make work faster, but the features for shell programming (writing shell scripts that other people will use) are not so useful. Yes, I'm aware of stuff like [[, I don't think that [[ is very useful. I have dash as /bin/sh and #!/bin/sh in all my scripts, and seriously, it's not a problem.
https://wiki.ubuntu.com/DashAsBinSh
(Note that Systemd has since obviated most of that work.)
You may be writing very different shell scripts than the ones which I encounter. I'm not sure what you mean by "variable expansion", because variable expansion is portable. Something like 98%+ of all pattern replacement I see is something simple like replacing a suffix or prefix of a string. For example,
infile=input.png
outfile="${infile%.png}.jpg"
Above a certain level of complexity, I'd likely rewrite the script in Perl or Python, anyway. Or possibly Go.
infile=input.png
outfile="${infile/.png/.jpg}"
At least historically speaking, Bash was noticeably slower than Dash. It's the slowest shell. If you are doing things like, say, build scripts in a CI environment where you need to execute shell scripts thousands of times or more, the 4x difference can make a real impact on user experience. Same thing during startup, back before the transition to Systemd, when Debian changed the /bin/sh alias to point to Dash instead of Bash to speed up system startup.
https://unix.stackexchange.com/questions/148035/is-dash-or-s...
https://wiki.ubuntu.com/DashAsBinSh
At some point, shell scripts reach a level of complexity where most people choose to rewrite them in a higher-level language, often Python or Perl, or maybe even Go. My personal experience is that the Bash-isms, although kind of nice, don't really shift that threshold... like, although Bash has arrays, but if I need to manipulate arrays, I switch to Perl or Python. If I just need to pull elements out of one array, I can do that portably.
Python has an enormous overhead compared to shell scripts, though. If you're writing some simple wrapper in a build system that's going to be invoked thousands of times for a single build, Python could easily end up being a choke point.
If you're really concerned about portability, I would probably write it in Perl :-)
Perl is basically a souped up shell language, with built-in Awk & Sed, faster start-up time than Bash, and it's installed nearly everywhere.
In terms of build systems, what I have most experience with would be with Debian and their build system, which pulls in the required dependencies. Compatibility in this space is less about zsh vs bash and more in line with architecture difference like RISC vs AMD64.
Whilst I broadly agree with your point, I'd suggest that "better experience" can be extremely "eye of the beholder" - especially if it interrupts a long established workflow / toolkit.
That's a bit of a non sequitur: Plan 9 is very much not a standard, and indeed it derives a great deal of its power from not implementing the POSIX standard.
Nothing's worse than the cult of POSIX. Half a century ago some people gathered and figured out the lowest common denominator of all the unixes of the time. Now it's 2021 and we're still supposed to restrict ourselves to this "standard" system in the name of portability. POSIX has so few features that restricting yourself to it is masochism. Every unix adds their own extensions, they would be almost unusable if they didn't. So why is GNU criticized for doing the same?
The author says GNU is just some optional userland. I find that amusing since in every traditional unix the POSIX userland is deeply integrated with the system. He talks about glibc but the BSDs and even Windows ship with their own libc that I can't ever get rid of because they're the only supported way to interface with the kernel.
Linux is the only operating system that actually frees us from this cult. Unlike other systems, the kernel/userspace interface is stable and defined at the lowest possible level: processor instruction set architecture.
https://man7.org/linux/man-pages/man2/syscalls.2.html
https://man7.org/linux/man-pages/man2/syscall.2.html
https://github.com/torvalds/linux/blob/master/Documentation/...
Only on Linux is GNU truly just some optional userland. You can throw it in the trash if you want. You can make your own. Who says you gotta have little commands like cp, mv, grep, sed, whatever? Who says people have to use some "standard" shell from the 80s? You can make a graphical userland if you want. A 100% Rust or Lisp userland. Even no userland at all.
People complain about systemd but I actually have a lot of respect for it. The developers had the balls to trash all this sacred POSIX stuff and make something new that actually uses Linux kernel features. The resulting system is better for it.
If you follow the FSF's actions closely, you will find they're incredibly insecure about people switching away from their software to alternatives. Typically the alternatives are not GPLed but rather under a permissive BSD-like license, and they latch onto this to deride any new competitors [1]. But those competitors don't typically exist because people hate the GPL; they exist because -surprise- GNU software isn't the be-all end-all, and it's a fairly common pattern for GNU maintainers to be reluctant to change at best, or actively hostile to third parties at worst (anyone remember glibc's Ulrich Drepper?).
Then there's how Stallman vetoed GCC having a useful AST output mode (a requirement to build smart IDEs and other development tools - yes, including such features in emacs) because he was scared of third party proprietary extensions. That's one reason why clang took off - its extensibility and flexibility, which the FSF was always against GCC having. The FSF (and particularly Stallman) hates clang, again reaching for licensing and moral arguments, because they just can't accept that some people may have written technically superior software to theirs, and done so with a more permissive license. [2]
In the end, it's hard to see the FSF's response to these things are anything but controlling and attempting to stifle competition. And we absolutely need competition for a healthy free software ecosystem. There is no value in trying to represent GNU as some kind of indispensable component of a Linux-based OS - they aren't, and pretending they are hurts us.
Well, if chrome is the primary set of userspace tools, "chromebook" might be a reasonable name.
I'm not sure how to differentiate android/linux (or even Chrome/linux) from UNIX-philosophy/linux, whether UNIX-philosophy ends up being busybox or GNU or something else.
A fact that termux people refuse to accept, hence why it doesn't run on the latest versions, unless they now finally accepted that POSIX isn't part of the official NDK stable APIs and have started calling into JNI.
Plenty of Linux software won't be compilable just with these APIs, unless they are game based,
FWIW, Termux works perfectly fine on the latest version of Android - what they can't do is push updates through the Play Store, because the minimum required API level now imposes security restrictions (no running executables from your data directory) that break it. But that doesn't make Android not a Linux system; you can still adb shell into it and run commands and shell scripts and copy new binaries in and run them.
This is not unlike Linux container systems, which also break various apps. It comes with the territory of containerizing applications that you have to break insecure legacy APIs; this is not unique to Android.
Regular users don't have any idea what adb is, and it requires developer mode to be enabled.
> The FSF (and particularly Stallman) hates
> FSF's response to these things are […] controlling and attempting to stifle competition
The “hate” seem to be all on your part.
I have a whole Twitter thread on how the modern FSF's policies actually hurt user freedom while being completely inconsistent with their own ideals, if you'd perhaps consider opening up your mind to criticism of them: https://twitter.com/marcan42/status/1377899929209774081
I support user freedom. I support users having control over their own devices, knowledge of what software runs on them, and knowledge of what choices are available so they can make an informed decision. I spend most of my time working on reverse engineering and porting Linux to proprietary hardware (Apple M1) so users have the freedom to run whatever OS they want. I cannot support the FSF, an organization which supports censoring security vulnerability warnings when fixing them involves updating proprietary firmware (that already exists anyway); that supports burying proprietary firmware in non-introspectable read-only memory because then they can "pretend it's hardware", then selling the result as "fully libre" (even though the same device with the same firmware visible and accessible to the user would be much more free and transparent, allowing introspection, auditing, and replacement with a free alternative); that supports physically destroying hardware components that presently require a proprietary driver to function, ignoring the possibility that free software drivers might appear in the future. These are real FSF policies and actions. This is what you are supporting when you support the FSF. It's not user freedom any more. It's religious nonsense like "blobs in /lib/firmware are bad, we can't have any blobs be out in the clear".
Totally agree, they have been completely swallowed by their own ideology. This shows that their actions are contradicting the same things FSF says publicly: that reverse-engineering is important.
That's a GitHub issue title filed by an FSF director on a project whose goal is to rewrite the basic POSIX core utilities in Rust, for security and maintainability. Because they MIT licensed them. They are literally telling a new competing project that they are worthless and an attack on the FSF due to their license choice.
> They are literally telling a new competing project that they are worthless and an attack on the FSF due to their license choice.
If that’s your interpretation of that quote, I’m not sure I can help you.
Although you can pay the FSF for copies is (I think) possible calling GNU a vendor similar to "MS or Apple" is too much of a stretch. When "MS or Apple" contributes back agreeing to the license, out of goodwill or because it helps the development, it is a nice behavior in their part; otherwise they are just being themselves.
As for why GNU is a different case with regards to extensions... I can think of a few reasons:
- The extensions are useful for a reasonable part of the users.
- GNU is free software, so you can easily use and benefit from the extensions.
- GNU is portable and its license allows even proprietary systems to include it without any problem.
- Some of these extensions can be disabled.
- Some of these extensions do not break portability if not used.
- Some of these extensions helped to shape and evolve what people expect from a UNIX-like system. A few GCC extensions influenced the ISO-C standard.
Of course when Linux became a viable they decided to abandon their plan and concentrate resources on userland. Kinda opposite to the usual of similar projects being co-developed leading to fragmentation. If there's an already capable kernel, why write another?
Another problematic point is the "look how much lines it takes, such a bloat" for `yes`. And then proceed to call it convoluted for pointless reasons. I guess being[1] about 100x (you read that correctly) faster is a pointless reason if a binary program you use rather develop can be written in fewer lines of code. Those GNU devs really should be more lazy.
Also there's "portability". If you write a program that is utilizing Linux' specific calls then your program isn't portable to other Unix-like systems. Same way that if you write `/usr/bin/env bash` at your script it won't be portable to other shells. You can of course install some POSIX utils implementation and use those, and you'll limiting yourself, but at least you'll have portability to systems you aren't using.
[1]: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
Needs correction.
As for the "horrible implementation" part... People nowadays don't realize how it worked in practice. Many extensions, like in GCC, appeared because people needed them (and at least in the case of compilers they're clearly marked as such). Also, at the time the GNU utilities were superior to native tools. Many Solaris admins started by installing GNU tools to make the system more usable, for example. If GNU was really so terrible, why would they do that? It's very easy to criticize it now, but it was a huge effort by thousands of people and I'm vert grateful to all of them.
The difference is the license, stupid. You have the source code. It's portable. You can compile/change/run these tools anywhere. It's not vendor lock-in when it's GPL licensed. If you become locked-in because you've really embraced a GNU extension of a "standard" tool, that's probably OK since you can use that same version of tool anywhere.
The GNU tools are effectively standard. But hey, just keep railing against them because you don't like RMS or the GPL or whatever axe it is you have to grind. They really are just tools.
Because POSIX (and partiall also ISO C) is just ex-post stadardization of features that appeared first as vendor extensions, and also does not cover many areas entirely. Useful extensions became part of standard, and also many programs just need to use non-standardized parts of API (e.g. some Linux-specific parts).
written, and been part of writing a suite of tools that have enabled the creation of an emormous catalog of software.
A lot would not have been possible without having access to a free compiler and all the other tools needed to write the software you dreamed of?
Most of it with no connection to GNU or RMS.
What tools did you think an ethsutiastic student in Finland hasd access to to start writing a kernel?
If you want to purge RMS and GNU from your life, go for it. Just make sure you also purge all the code created due to it.
Hurd failed? Sort of. Who cares?
He has done more good, helped more people, enabled far more people to use computers, and enabled enormous fortunes to be made.
Do you think something you write will be used by bilions of people for decades?
You do not like him, you do not like his ideology, who cares? Dont trivialize his accomplishments.
At least not until you have done the same and much more.
Just to be clear, Ariadna Vigo is not attacking computing freedoms; pretty much the opposite. I agree with her position on nearly everything except for her stance about the GNU operating system. This is a technical detail in the grand scheme of things. Just like tabs vs. spaces, for which it is fun to disagree in an over the top way.
We must support the FSF for pragmatic reasons, but we can still acknowledge that the "pure unix" philosophy is a great and beautiful idea. Also, cat-v and suckless are fun websites full of interesting stuff.
Hurd or seL4...but obviously no one is interested in such an Kernel for servers, mobile or the desktop.
From MY perspective, the OSS OS community was in a much healthier state in the ~05's then it is now (Linux, BSD, Solaris, Minix etc) where all maintained and gave plenty of selection of ~OSS operating-systems, now it's just that Linux.
Middle layer is networking, file systems, ACL, monitoring, graphics and other acceleration in a rich os. Or monolithic deterministic real time blobs. Or small dedicated OS partitions for, security or similar hardware jailed applications.
Top layer is containers/jails inside the rich OSs.
Then fuchsia is a candidate for the bottom layer and for the security OSs and maybe for specialized OCI payloads.
Edit: Linux is not a OS but a Kernel...got it? Your should know the difference as a Windows/UNIX person ;)
By the way I am a Windows/UNIX person, note the UNIX part.
The FSF is not the Linux Foundation
Fucshia is already shipping on the Nest, lets see what happens next.
Excluding Google (Fuschia) and Huawei (HarmonyOS).
The whole article didn't mention even one concrete thing the FSF has said wrong, it just slanders them several times. No wonder it says to the FSF "don't bother to contact me."
Level 0 There are other x86 OSes?
Level 1 GNOME sure does look pretty (Ubuntu)
Level 2 What... is this for, anyway? (Mint)
Level 3 Oh, it's for privacy and independence (Android, AOSP, non free kernels)
Level 4 OK, then, let's build it ourselves (LFS)
Level 4.5 You can't (hardware blobs)
Level 5 Er that was a lot of work (Gentoo)
Level 6 Wait WTF is systemd (Arch)
Level 7 Bleh, pacman doesn't have a gui (Manjaro)
Level 8 Wait, Ubuntu is based on what? (Release schedules, Arch vs Debian)
Level 9 WTF is a userland? OSX is based on what? (Alpine) (MIT. BSD. GNU. RMS. FSF. LLVM.)
Criticizing GNU for providing features is absurd.
Users need features, not phylosophycal purity.
Software needs less politics, not more.
> If you thought I was going to go the “Android route” of argumentation… You know… saying that Android shows that Linux can be used without GNU… Sorry! I’m way more sophisticated than that!
Sophisticated in what sense? That when you search the Android source tree you find FSF code?
https://cs.android.com/android/platform/superproject/+/maste...
FWIW, here's a search for FSF-copyright code that excludes build generator output (autotools/automake/libtool/etc) and gcc/bison/etc related stuff (which many other projects which are not themselves FSF-authored use), as well as licenses themselves:
https://cs.android.com/search?q=copyright.*free%5C%20softwar...
193 hits, and a lot of that is ffi and libbacktrace stuff. Exclude those two projects, and you're down to 47 hits, most of which are random things like headers, test shell scripts, and some translations. I think it's fair to say that Android does not include any significant amount of GNU/FSF code.
(Keep in mind that the Android codebase is massive and vendors a huge amount of third-party projects, so it's actually quite remarkable that there is so little FSF code in here - part of that speaks to how little FSF people contribute to other projects!)
With that in mind, I would say the number of people who use such a thing to run their business on (rather than deleting any reference to it in the first 10 seconds of trying to use it) says a lot more about the cultish behavior of tech enterprises than the linked blog post does.
I always blamed MacOS/BSD for just being different, but now I know that it's GNU that is different. I'm not sure what to think about it though--I do like the idea of compatibility with a standard, but I also don't like standards to hold back innovation.
Commercial unixes "based on" SysVR2/3/4 had plenty of "non-standard" behavior and extensions, it was how you differentiated your product. You support POSIX compatibility to enable portability if you need it, but you differentiate with your extensions or "weird behavior". GNU was no different. The BSDs just have their own tradition, one that's older than POSIX.
This command generates a strong password. How do you do it with only posix?
tr -cd a-zA-Z0-9 </dev/urandom | dd bs=1 count=32 2>/dev/null; echo
But uuencode exists in the POSIX standard. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
I don't think POSIX even defines any functions/system calls for getting cryptographically secure random numbers, so if you're literally restricting yourself to POSIX constructs, then indeed what OP asks for is impossible :)
You may need to be careful because the major number is shared with /dev/null, but I doubt these numbers are hardcoded in many places.
You could add a new major that does this (keeping the old numbers for compatibility), but I think you'd have a hard time convincing people that this is a worthwhile enough idea; hard-coded new major numbers are in short supply.
head -c 20 /dev/urandom | md5sum
Besides the lack of portability to other Unix systems isn't a real problem. The operating system itself is portable! /s
Just wanted to point out https://jmmv.dev/2021/08/useless-use-of-gnu.html, which also covers the portability problems that GNU has widely introduced and describes alternatives to the common issues.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
1956
Thanks the the consent decree from 1956 AT&T wasn't allowed to enter new markets and license patents royalty free, what we got was UNIX and C and open code. They regulated AT&T positively! Probably the best thing the United States Department of Justice did. They ditched capitalism and everything got better by magnitudes!
1983
The US Department of Justic setteled a consent degree with AT&T. Probably the worst thing the Department of Justice did. They allowed them to split up and do whatever they would. Full capitalism! Since then the US have seen no market regulation. What followed wear UNIX-Wars, lawsuits and finally companies like Microsoft, Google, Amazon, Facebook and Apple.
You want blame someone? Blame the government. But I see two lessons. The regulation has worked. Single fines (punishment) or splitting about doesn't. AT&T is again the largest telecommunication company and UNIX was busted.
I'm thankfully for what we learned from UNIX, that POSIX gave us some guidelines in the past, the C Language and finally all the descendants - Linux, GNU, C++, GCC, BSD Network Stack and GCC...and finally LSP (works wonderfull with NEOVIM and CLANG).
Huh? Torvalds never intended to create an operating system, just a kernel, and that is true to this day.