TeamBlackFox wrote:
Understand Kumba I'm not against individual developers of GNU/Linux, but all my research points to real innovation coming from BSD, and only questionable enhancement from the GNU/Linux side that takes several attempts to get a half-working solution.
I think both camps have had their moments of innovation. gcc was, by and large, the first freely-available C compiler. Though, gcc largely worked out fine until GPLv3, whose more restrictive licensing led Apple to kickstart the LLVM project and then Clang. Ironically, I see that as a good thing because now Clang's existence gives gcc some competition. And both teams do work together from time-to-time, too.
On the BSD side, you've got the old debacle of XFree86 when they switched to that extra-clause BSD-like license that caused everyone to run back to the original X.Org. This led to XFree86 being abandoned and a lot of problems that had been "stuck" for a long time (namely its build system and lack of modularity) getting addressed in the X.Org releases. We even have X11R7! How long were things stuck on X11R6? This also led to spinoffs like Wayland and Unity. I have yet to check them out, but again, more competition and different projects trying different ideas out.
Mind you, there's also the case of
too
much competition. There's a thin line between too little and too much competition. This is why on one hand, I welcome systemd, but on the other hand, dislike it. But more on that later.
TeamBlackFox wrote:
Device handling: Devfs did need replacement, but HAL made the situation worse with its constant polling and dirty hacks. Udev fixed the problem mostly, but now that's tangled into Systemd. Before you say eudev, I used Arch prior to moving to BSD, and by far it was the best GNU/Linux experience to date. I used eudev, sysvinit and netcfg for device, init and network over systemd for all three. However this broke half of the packages for Arch, made the Arch build system break, and D-bus constantly misbehaved. Point is, I'd love to use a solution that WORKS and doesn't involve me going into Gentoo level of difficulty ( BSD is far easier than Gentoo to setup, even with 'shortcuts' ) On BSD, they now have devd, which can use HAL, but isn't made to, and choosing to not use something like HAL won't break half your packages/ports.
To be honest, I like FreeBSD's idea of device management. You've got the kernel piping out a stream of text data to /dev/klog and a listener can monitor that stream and handle device events as they come through. That's how I saw it explained in a nutshell, anyways. And their devfs/devd rule syntax looks a lot cleaner than what you use in udev. It fits with my idea of the kernel dealing with the actual hardware notifications (which is kind of the kernel's job) and allowing a user-space daemon to manage setting up that hardware. I think it'd be interesting to see that ported to Linux, if someone ever gets the incentive to do so.
HAL, I don't know much about because I never used it. I am very minimalist in my approach to systems, and I prefer to start small and build up, instead of start with everything and strip it down. This is why Gentoo works well for me (and in a pinch, Debian). While I wish your experience with Arch was a lot better, I believe they have cast their lot in with the systemd crowd and so, that will be your only option as an init package. But, given the complexities of maintaining a binary-only distro, I'm not entirely surprised at their decision, either. A lot of Linux distro developers, like their BSD counterparts, aren't paid for this, so sacrifices have to be made somewhere.
TeamBlackFox wrote:
Init system: Sysvinit, if configured BSD-style, didn't have any serious problems other than the method of action, Runit and OpenRC works, but Systemd doesn't! Why the hell does my server need D-BUS if its just a frigging webserver??? Literally on OpenBSD I can fire up NGINX within minutes as it is in base, add my files after some config, good to go!
You will find me in agreement on this. But, like gcc and clang, I think systemd's positive aspect (if it is possible for it to have one) is that it added competition. Sysvinit was great for many, many years. It's a pity that OpenRC wasn't more widely known about years ago -- maybe that would have put off systemd's creation a bit longer.
But sysvinit's main flaw was its lack of parallelization and to a lesser extent, a dependency-based startup model. OpenRC largely fixed the latter problem in a sane fashion, but the parallelization bit is a tough nut to crack with a shell language. Personally, I don't care much for parallelization. I use Windows in my daily work and it's startup speed leaves a lot to be desired. My Octane can boot Linux in about ~20 seconds, and that is plenty fast for me. People pining for 2-second bootup times befuddle me, but humans are weird, yo.
So that's why we have systemd now. As a technical project, it's refreshing to see new ideas being tested out, and maybe we'll see core sysvinit development fire up again as people finally have an incentive to go back and look at the old code. What I don't like is the culture around systemd. Many of its proponents could use a few lessons in tact, at a minimum. Especially needing to accept that not everyone wants or needs systemd's capabilities. Here's a fine example of the arrogance that pervades the systemd culture:
https://wiki.debian.org/Debate/initsystem/systemd
:
Systemd is becoming the de facto standard init system for Linux. It replaces the venerable SysV init with a clean and efficient design, and brings a stream of new functionality that makes the life of users, administrators and packagers easier. It is better than existing alternatives for all of Debian’s current use cases:
-
Application and infrastructure servers benefit from reliable and easy service management, cleaner dependencies, service monitoring, security features and global system integration.
-
Desktops, laptops and session servers benefit from session management, multi-seat, unified system interfaces, as well as integration with udev, D-Bus and other system services.
-
Embedded systems benefit from speed improvements, shell-less design, ability to remove optional components, and lower memory footprint.
Systemd represents a leap in terms of functionality, one that is comparable to Debian’s existing improvements over other operating systems. People are starting to expect this functionality when running Linux, and missing it could, in the long term, make Debian lose its purpose.
That last line, especially. The veiled, unsubstantiated threat of future doom if they don't switch to systemd. That's an eye-roller if I ever had to pick one.
TeamBlackFox wrote:
D-bus: I'm gonna get flak here, I know, but I don't see the point. Sockets by themselves work fine for IPC, and while adding a common way for processes to communicate is cool, why not just implement message passing as DragonFly BSD is doing? AmigaOS proves the message passing model works.
Another component that I avoid using if I can. I believe there is talk of migrating a portion of dbus into the Linux kernel (kdbus), but I don't know the status on that. I've half a mind to wonder if maybe this isn't something IPv6 can solve. With trillions upon trillions of addresses available, just take advantage of the fact that most systems have a loopback device and use the existing network stack to dynamically assign each application a device address. Then just pass messages using whatever transport protocol of choice you want. But, eh well.
TeamBlackFox wrote:
In any case, I have no problem using MIT/BSD licenced kit from the GNU project or any of the GNU/Linux distros, as all of it I have come along is innovative, good material. The same can't be said for GPL stuff, its more like, there's nothing better to use, if you have to use it. Nobody uses it because they want to. Nobody on the OpenBSD project builds code for VAX, Alpha or another dead architecture on GCC because it's good, it's because there's no real option!
And sometimes, nothing better to use is the case because no one cared enough to make something better. Humans can be an amazingly lazy species sometimes, and "good enough" often works very well for large numbers of people. If more people would stop accepting "good enough" and be willing to go those extra few miles to make "good enough" into "fuck yeah, Seaking!", you'd see a lot better code and projects out there.
TeamBlackFox wrote:
In regards to how GCC mangles code under -O3, all I know is, when I'm running code through -O3 to ensure I've not overlooked any bugs at that level of optimisation, the same program run under clang doesn't fall apart when run at that high level of optimisation, but GCC does, quite frequently. I don't care to learn enough x86 asm on my server to understand the code, all I care is: Does it break?
Odds are likely it's not the compiler that's breaking, but you're just compiling code that had certain assumptions built in. The most common assumption being no one uses anything above -O2. I don't know if it's still this way, but it used to be that if you joined the #gaim channel on freenode (what pidgin used to be called), and started asking questions about why something wasn't working, and then the devs find out you're a Gentoo user, they permabanned you, no questions asked. Usually because that user used -O3, along with a whole bunch of other obtuse gcc flags, built the code, and then assumed that the code was just broken, not their choice of flags, and the devs just wouldn't have any of that. They coded things to be used with a certain optimization level and anything else is broken and wrong.
This isn't something specific to gaim/pidgin either. FreeBSD has dedicated an entirely separate variable for compiler optimization flags for the kernel ($COPTFLAGS), and they're pretty clear that -O2 is the highest you should go. I'm sure other examples exist out there, too.
Keep in mind the insane job that a compiler has to do. In the case of gcc, it's got to take a largely architecture-neutral coding language (C) and output architecture-specific assembler code for a dizzying number of different machine architectures. And with MIPS being a prime example, an even further dizzying number of ABIs and ISAs. You're going to get bugs in there at some point (as my discovery of the R10000 regression in PR61538 is a key example of).
Clang is a new approach to the same old problem. It has an advantage in that, it is able to avoid many of the mistakes that gcc has encountered and solved over the last 20+ years. But in time, Clang will encounter its own problems and they'll have to be fixed. Maybe gcc will borrow that fix, or maybe gcc will be what inspires or contributes the fix? Time will tell.
TeamBlackFox wrote:
Let me say this though: the GPL's viral nature as a licence that anything it touches must be GPL too is the single most aggravating thing about it. I have less of a problem, significantly less, with the LGPL and CDDL. What pisses me off further is that some people take pride in that and say it's in the name of freedom. By that statement, they're no better than the police officers who abuse people in there custody and say it's in the name of freedom. If the GPL backed off that then I'd just licence my contributions under the ISC licence and build a patch against the original program.
And this is the point upon which many disagreements have been discovered. GPL and BSD are both free software licenses, in a sense. I think what it boils down to is that GPL is more idealistic in its design than BSD is. GPL wants to ensure that code remains free, open, and accessible. GPL wants to make sure that everyone's contributions are recognized. It's a very....
kumbayah
kind of thought process. Borderline socialism if you ask me.
BSD, I think, is more designed by realists. BSD places extremely few restrictions on the code developer, so it is arguably the more "free" license. It prefers that code remain open and free, but it doesn't require it. It's a very relaxed license, in my opinion.
Also, if you look around, you'd be surprised at the number of camps that hijack the word "freedom" for their own use. Freedom is an idea that can never be truly realized by an organic species that desires to survive. True freedom is chaos, anarchy, high entropy. That is not compatible with life as we know it. Freedom with restrictions placed upon it, now that is something that a species like ourselves can survive in. It's just a question of how many or how few restrictions do you place. Everyone has different tolerances of freedom. Some like things to be highly ordered, rigid, stoic (less freedoms), while others like things to be very fluid, dynamic, spontaneous (more freedoms). Some like salt and pepper on their eggs, while others like Tabasco sauce. Some like the GPL and others like BSD.
So next time you see someone chortling on that the GPL is more (or less) free, ignore them. Don't let it get to you. Enjoy whatever it is that you like the best.
4x R14000
4x R16000
1x R16000
2x R14000
RM7000
R10000
R4400
R10000
R8000
4x R14000
R5000
