Obviously you've never had to switch out a library or framework before, or done anything cross-platform. The author talked about writing libraries that sit on top of the API, not simple thin wrappers.
It also manages access to the display driver and the actual session. And yes, the same job could be done by another piece of software, but none have been written that I am aware of. That is also true of any piece of software, so I'm not sure what your point is.
Nice summary of requirements for non-root X: ehttp://hansdegoede.lvejournal.com/14268.html
The point is 1.15 couldn't, and 1.16 can with systemd components. I think calling development builds of the 1.16 branch "previously" is quite disingenuous.
Totally agree. When I read his analogy it initially made sense to me, but only because I implicitly switched the order of Systemd and SysV init because that makes sense. "abomination that does "everything" complexly and half-assed" perfectly describes the hell that was init scripts.
The latter. Prior to this change it was impossible to run X as non-root, it took significant work (and a more capable init system) to support non-root X.
Or a random guy blew up something, why didn't the CIA/NSA/FBI know that he was doing this...
If those organizations are going to continue receiving more money, more privilege, and less oversight in the name of protecting us from terrorists, then they deserve blame when they have nothing to show for what they have taken from us.
Commenting to fix mis-mod - accidentally modded flamebait, but sublime was the first thing that came to my mind as well.
Off-topic - this was actually the one thing I thought the beta made better, the left/right split of positive/negative mods as well as larger hit boxes, I think it will reduce this kind of error in the future (I mean.... #betasux).
The benchmarks on Phoronix did temperature, and commented on (though didn't measure) noise. Was actually a fairly comprehensive, well done benchmark, the only thing missing was frame latency measurements.
Just because you can point to one microkernel that doesn't really work, and one monolithic kernel that does, will not invalidate the perfectly valid points made about the benefits of modularization. Yours is just a logical fallacy:
eg. "I'm sure everybody that likes bicycles never drives a car..."
Except it's not valid points made about modularization in this context. It's a blanket statement that modular is better, for which a single counter example is sufficient to disprove. The AC's post didn't mention specific flaws with systemd, instead they asserted generalizations about how modular is better than monolithic. Just because there are potential benefits to a modular system over a monolythic system does not mean a specific modular system is better than a specific monolythic system, leaving the AC's post as little more than FUD.
This is not the point or benefit of the original UNIX and much of the Linux architecture. By doing small tasks well, a reliable toolchain can be built of those small tasks. *OF COURSE* a monolithic megamonster is going to have fewer lines of code than all the different components shoe-horned into it. And of course *it's going to get details wrong* in those individual components, but the monolithic megamonster may rely on those flaws or make debugging of them unreasonably difficult.
I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.
The relevant "or later" clause from GPLv2 is Section 9, for those who are curious.
The point being, Linus could have allowed later versions of GPL. He explicitly decided to disallow them from the start, and has defended that position repeatedly.
The Linux kernel is stuck on the GNU v2 license for exactly this reason, and can never change. That's the fate of any such non-CLA'd Open Source project (other than something using Public Domain or the BSD license).
Actually no, the Linux kernel is stuck on the GNU GPL v2 because Linus made that decision on purpose. The default GNU license allows for relicencing under any later version, but Linux removed that clause on purpose.
60% of the Canadian public votes against the Tories
That is not even a little bit true. Only 61% of the Canadian voting-eligible public voted at all in the last federal election. Of those that did vote, 60% voted for a different party, not explicitly against the Tories. Our electoral process is not configured to allow one to vote against a party.
I'm not sure how you got "a pcie bridge over wires rather than on board connectors" from "Expose devices as hotplug PCI-E". Presenting devices to the operating system as PCI-E hotplug in no way implies they actually are PCI-E devices or are in any way electrically similar (much like how "file descriptor" hardly means "file").
In short, I agree with everything you said in the second paragraph, and I think it supports my point. The OS (local CPU) only gets involved with the Thunderbolt controller for communication relevant to it. The controller chip hides all the complexity of packet switching and routing etc. Unless you're on a Mac, which takes all that brilliant design and says "We're going to require the kernel to manage everything the controller chip should be doing for us".
Actually, Thunderbolt on Macs deviate from the specification a fair bit. The Thunderbolt spec is simple: Expose devices as hotplug PCI-E, let the BIOS do everything.
Slashdot Mirror
Obviously you've never had to switch out a library or framework before, or done anything cross-platform. The author talked about writing libraries that sit on top of the API, not simple thin wrappers.
It also manages access to the display driver and the actual session. And yes, the same job could be done by another piece of software, but none have been written that I am aware of. That is also true of any piece of software, so I'm not sure what your point is.
Nice summary of requirements for non-root X: ehttp://hansdegoede.lvejournal.com/14268.html
Sure, if you were building dev releases. And as per patches like http://lists.x.org/archives/xo..., you needed systemd-logind.
The point is 1.15 couldn't, and 1.16 can with systemd components. I think calling development builds of the 1.16 branch "previously" is quite disingenuous.
Totally agree. When I read his analogy it initially made sense to me, but only because I implicitly switched the order of Systemd and SysV init because that makes sense. "abomination that does "everything" complexly and half-assed" perfectly describes the hell that was init scripts.
The latter. Prior to this change it was impossible to run X as non-root, it took significant work (and a more capable init system) to support non-root X.
Per their help page, HD is 5Mbps, Ultra HD is 25 Mbps.
https://help.netflix.com/en/no...
The author's intentions could be summarized as, "Does this false dichotomy make me look smart?"
1) This actually shows how ugly web design loses popularity!.
For people who are two lazy to follow the above link: the thought, "Beta isn't so bad." crossed my mind when I saw their page.
Or a random guy blew up something, why didn't the CIA/NSA/FBI know that he was doing this...
If those organizations are going to continue receiving more money, more privilege, and less oversight in the name of protecting us from terrorists, then they deserve blame when they have nothing to show for what they have taken from us.
The sample size of total number of Tesla's is statistically significant. Total size of population relative to ICE vehicles is irrelevant.
Not all of us have access to the time machine required to know *which* 1TB that is.
Are you willing to share yours?
Commenting to fix mis-mod - accidentally modded flamebait, but sublime was the first thing that came to my mind as well.
Off-topic - this was actually the one thing I thought the beta made better, the left/right split of positive/negative mods as well as larger hit boxes, I think it will reduce this kind of error in the future (I mean.... #betasux).
The benchmarks on Phoronix did temperature, and commented on (though didn't measure) noise. Was actually a fairly comprehensive, well done benchmark, the only thing missing was frame latency measurements.
Yeah, but it tab completes, so on the other hand it's the only word you have to type and the only spelling you have to get correct.
My biggest gripe with service is that it doesn't support tab-completion.
Just because you can point to one microkernel that doesn't really work, and one monolithic kernel that does, will not invalidate the perfectly valid points made about the benefits of modularization. Yours is just a logical fallacy:
eg. "I'm sure everybody that likes bicycles never drives a car..."
Except it's not valid points made about modularization in this context. It's a blanket statement that modular is better, for which a single counter example is sufficient to disprove. The AC's post didn't mention specific flaws with systemd, instead they asserted generalizations about how modular is better than monolithic. Just because there are potential benefits to a modular system over a monolythic system does not mean a specific modular system is better than a specific monolythic system, leaving the AC's post as little more than FUD.
This is not the point or benefit of the original UNIX and much of the Linux architecture. By doing small tasks well, a reliable toolchain can be built of those small tasks. *OF COURSE* a monolithic megamonster is going to have fewer lines of code than all the different components shoe-horned into it. And of course *it's going to get details wrong* in those individual components, but the monolithic megamonster may rely on those flaws or make debugging of them unreasonably difficult.
I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.
More than one worker drowned in concrete during the construction of the Hoover Dam, and there are bodies entombed in the blockwork.
Apparently that is a myth: http://nsla.nevadaculture.org/...
Thanks, my kernel also says that ;)
The relevant "or later" clause from GPLv2 is Section 9, for those who are curious.
The point being, Linus could have allowed later versions of GPL. He explicitly decided to disallow them from the start, and has defended that position repeatedly.
The Linux kernel is stuck on the GNU v2 license for exactly this reason, and can never change. That's the fate of any such non-CLA'd Open Source project (other than something using Public Domain or the BSD license).
Actually no, the Linux kernel is stuck on the GNU GPL v2 because Linus made that decision on purpose. The default GNU license allows for relicencing under any later version, but Linux removed that clause on purpose.
Here's his rant against GPLv3: https://lkml.org/lkml/2006/9/2...
Pro tip: When someone does something retarded on the internet, don't point and claim responsibility.
That dependency graph is beautiful.
I wish gcc had a --fno-circular-dependencies flag to force that on a codebase (much like go does in the language spec).
60% of the Canadian public votes against the Tories
That is not even a little bit true.
Only 61% of the Canadian voting-eligible public voted at all in the last federal election.
Of those that did vote, 60% voted for a different party, not explicitly against the Tories. Our electoral process is not configured to allow one to vote against a party.
I'm not sure how you got "a pcie bridge over wires rather than on board connectors" from "Expose devices as hotplug PCI-E". Presenting devices to the operating system as PCI-E hotplug in no way implies they actually are PCI-E devices or are in any way electrically similar (much like how "file descriptor" hardly means "file").
In short, I agree with everything you said in the second paragraph, and I think it supports my point. The OS (local CPU) only gets involved with the Thunderbolt controller for communication relevant to it. The controller chip hides all the complexity of packet switching and routing etc. Unless you're on a Mac, which takes all that brilliant design and says "We're going to require the kernel to manage everything the controller chip should be doing for us".
Source: same as before, from someone who has read the relevant spec and implemented a driver - http://www.kroah.com/log/linux/hardware.html
Actually, Thunderbolt on Macs deviate from the specification a fair bit. The Thunderbolt spec is simple: Expose devices as hotplug PCI-E, let the BIOS do everything.
Thunderbolt Macs go out of their way to... not that. Read more at http://www.kroah.com/log/linux/hardware.html.
Nevermind, I found what you meant - link 60 was dead, I checked out 59 (related, not as detailed as 60 promised to be).
I wonder if you could set up a plugin to connect the wayback machine to dead wikipedia references.