XFCE 4.10 came out in April/2012. I'm honestly worried maybe things have stalled. I use Funtoo(/Gentoo) Linux, so I see from time to time things get updated in the various applications that make up XFCE, but I'm still worried about its future.
Just a simple question - if it works for you, unless there are some major security bugs or something, why does it matter if it gets 'updated'?
I've been in unix for over 20 years and never even heard of kill -1.
That's very honest of you. Don't know what you've been doing in Unix, but not knowing how to issue a SIGHUP signal (or why) after working with Unix for 20 years is not particularly a recommendation.
Probably best not to mention that on any future interviews.
To be honest, I've had to explain signals (in general) and SIGHUP to a lot of newbies over the years - it's certainly not something I would expect an *experienced* sysadmin not to know though, and if I was interviewing someone for a sysadmin job who supposedly had "20 years" experience and couldn't tell me at least a few of the *myriad* ways SIGHUP is used in unix - even if not explicitly by them issuing a 'kill -HUP' or 'kill -1' command (many daemons, etc), I probably wouldn't hire them.
I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?
Um, you "use" kill -1 *every* time you use "crontab -e", you also "use" it (the SIGHUP signal) for a lot of other things probably, like forcing apache httpd to re-read it's config file, or any number of other similar things where you can make an app/daemon re-read it's config. And if you drop your connection to your login shell without logging out first, it gets a SIGHUP as well.
It has nothing to do with linux/unix being 'unreliable'.
I would say the same thing, but there are several countries that can effectively impose their will anywhere within the Moon's orbit and a handful that could manage anything within the solar system. That said, having navigational control of a big rock on the edge of a gravity well may prove to be a hefty bargaining chip.
I've used your analogy before. And USA law is that the USA corporation is legal obliged to instruct and take measures to get the data from the UK subsidiary. Nothing is changing here this has always been the case.
Which is, in effect, saying that MS then would have to take their UK subsidiary to a UK court to get a ruling, spending their own money taking themselves to court, in essence. That really should be for the US courts (prosecution) to take up with the UK court, shouldn't it? I mean, the whole concept of "me suing myself, and having to hire *both* prosecuting & defense attorneys" is ludicrous...
No, the evidence is not the property of a US company. The evidence is the property of a US citizen and is being held by a foreign subsidiary of a US company and is, therefore, exactly like the hotel example.
The world really would be simpler if we stopped trying to define how information on computer is the same as information on paper in some circumstances and different in others and just say that correspondence is correspondence, personal effects are personal effects, etc.
Which is, I would think, what MS is trying to do... get the courts to rule on it, one way or another, from the highest court possible.
NDAs are to cover technology or "trade secrets" - writing a review for "peppermint Coca-Cola" (making something up) saying "it sucks moose balls" isn't revealing their 'recipe' for making it or anything secret, anyone can buy a can and make their own judgement.
By the same token, even if I enter an NDA with a company to, say, integrate their technology into a product - saying "these people are a PITA to work with and I would never want to deal with them again" isn't violating the NDA on their technology.
Now... I could see perhaps if you entered into a deal with say Rossi and the "eCat" cold fusion nonsense, that saying "they're a fraud, the technology is a hoax" might perhaps be a gray area - but still, as long as you're not revealing their 'secret catalyst' or the actual (non-) functioning details of the device, you aren't really revealing their 'secret' technology?
The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
So you're "fixing" a bad application by changing the OS?
Apparently that's the "preferred solution" now... to me it seems to make far more sense to fix the application (BackupExec) to work the way it should, but that type of "logic" apparently doesn't apply to the systemd people who think that the "proper" way to fix that is to write a complex init system replacement and continue to allow people who write shitty service/daemon code to continue writing crappy code.
It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
Sounds like those issues are implementation based.
Yeah, sounds like some work needs to be done fixing the init scripts rather than writing a whole new init system to allow people to keep writing crappy scripts?
and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and.
Ok - well your talking about desktop stuff here, which is an interesting perspective that I didn't really consider, however I still think that is doable in inittab with much less effort. rc is only a runlevel solution, whereas inittab would be more relevant to desktop. I don't need to keep track of the process and it's children because init can maintain the parents state for me - if the parent isn't signalling it's children then we are back to implementation issues again.
Yup, instead of tackling the real problem - poorly written services - their "solution" is to try to write a new init system to allow crappily written services to be tracked/"controlled", ignoring the fact that the crappy modular services should be rewritten.
I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.
jeeez. I'm just trying to figure it out. I'm not being a jerk about it, I'm trying to gauge other peoples experiences. I don't give a fuck about init if systemd is better - it's just another technology. But if it is better than shouldn't it be immediately apparent *WHY* it is better?
Yeah, and I don't see as it "fixes" anything other than adding a lot more complexity to "fix" things that it shouldn't have anything to do with.
It could be argued that such things are simply not the responsibility of the init system. I think that is where much of the complaints about systemd come from, the perception that it is taking the roles of other things and folding them into itself. Given how it has been expanding to include more and more services and has increased coupling, they kinda have a point. Many see systemd as solving problems that are philosophical in the first place as opposed to practical.
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
It's not supposed to - a *properly* written service would/could/should keep track of it's own processes, that isn't something init was ever supposed to do (be the 'micro-manager' of everything). If run the rc script to stop a service, and it doesn't stop all the associated processes, that is *NOT* a "problem with init", that is a problem of a poorly written/debugged service, and the code for the service should be fixed - not a whole new massively complex init system to "handle" it (or, in simpler terms, to continue to allow the people writing services to write shitty code because now "systemd will handle it").
That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1.
I will be clear that I am not a seasoned linux sysadmin; I know bits of Linux, I can manage a small installation, but Im definately not an expert. Im also not a seasoned programmer; I understand programming.
However I have had experience with a lot of badly written services on Linux where I've had to decipher the init scripts, or figure out why "service XX stop" doesnt actually stop the service, whatever stdout might claim.
It seems to me that the approach you are advocating works really well in a world where badly written services simply die out due to people rejecting them; in reality you have badly written services all over the place that get screwed up all the time. Your philosophy could be extended to say "we'll also have the kernel just manage cpu, disk, and memory, and leave handling the filesystem up to individual programs." Which works, as an engineering principle, but in the real world you will end up with filesystem corruption on a daily basis because you are causing the entire system to have a net increase in complexity.
From what Im gathering, systemd increases the base system complexity, but will (over time) ensure that those complex bits are stable (much like building FS support into the kernel). On the upside, it allows all of that complexity to be removed from all of the million other packages where 'building a stable init script" may have been priority 99 out of 100, and now they simply dont have to worry about that.
I see, so you are blaming the current minimalistic init process, that hasn't had any known/major bugs for decades really, for "badly written services all over the place"? Wouldn't that, instead, be something to push more for "better written services" about, rather than increasing the complexity of the init process?
Yes, as an *experienced* sysadmin (28yrs of Unix, from Edition7/earlyBSD to Linux/SysV, on everything from "big iron" to PC servers) I've seen poorly written start/stop scripts that don't do what they should, don't handle 'failure to stop' properly, etc. I've almost always been able to deal with it manually, in the rare cases it happened (HPOV was one of the worst, randomly left stuff running) I could fix it manually w/o a reboot, and if needed I could fix the script fairly easily (or submit a bug report to the vendor - even though they rarely fixed things like that very promptly). I certainly didn't blame the fact that some programs rc script was poorly written, or its processes were poorly written pieces of crap, on the init process. Under *any* Unix derivative I've worked on, well written services rarely needed a restart in the first place.
If the battery in your car dies, do you also launch an engineering team to redesign an entirely new car powered by a suitcase sized nuclear reactor, with all the increased danger that could involve if the 'unforeseen' happens, or do you just replace the faulty battery?
It may be an unpopular viewpoint, but this is why business is leery of the GPL and 3rd party contributions. Mojang should have been a little smarter before they acquired the toolkits and developers so they knew the ramifications of their purchase. At this point, it sounds like Mojang is being extorted since the code was never properly license in the first place.
Bingo. A lot of companies avoid GPL for just this reason.
You hit on one of the key words, "cleanroom". No code was contributed to Bukkit by people within Mojang with access to their internal repo. So the decompiled version is GPL while the internal version is not, thus no violation.
No, the decompiled version is still Mojang's code, it's not (and cannot) be GPL just because they decompiled it - any more than you could decompile a copy of MS Office, and say that the source to DecompiledOffice is now GPL.
They *stole* Mojang's MC code, in essence, by decompiling it and distributing it. Mojang was nice enough not to take them to court over it - but that doesn't mean the code is suddenly GPL.
(From GPL V3) A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
I would venture to say that the mod is not an "extension of a GPL3 covered work", in fact quite the reverse - it's an extension of a non-GPL work.
I don't see how the situation creates a GPL violation. It sounds, in fact, like the copyright that is violated is the copyright Mojang holds for Server, and Mojang has been kind enough to not press charges.
Sounds like it to me, they decompiled/reverse-engineered the Mojang *non-GPL* code, and Mojang was decent enough not to try to take them to court over revealing their own proprietary code. A lot of companies would have sued their butts off.
Right, the best way to prevent sophisticated American weapons from ending up in the hands of ISIS would have been to not hand them over to an incompetent sectarian asshat like Nouri Al-Maliki, the proper way to prevent that from becoming the only option would have been to not start a stupid war in Iraq to boost Halliburton stock prices, this in turn brings us to the most workable way to prevent America from starting a stupid war in Iraq in the first place which would have been to not elect a cheerleader for president.
Especially in the server world. The OS boot time is a fraction of my server's boot process. Starting out, you've got POST with RAM tests et al. The RAID array spins up and does its dance. Maybe IPMI gets in the mix. The NICs might have their own prompt for configuration changes lasting a few seconds. And sometimes the BIOS decides to give a detailed list of events with a ten second countdown (bypassable with a keystroke). Then some particularly silly BIOSes complain for a few seconds about a lack of keyboard. Finally, the MBR is touched. systemd will never speed up the slowest part of the boot process, so it's useless for that purpose in a server environment.
Yeah, in all honestly OS boot time has never been an issue for me on startup - it's all the other stuff... the BIOS memory test on a 64GB machine, followed by by probing all the cards for their BIOS's and delays for disks to spin up, etc. When the machine takes 5 minutes to get past the BIOS/hardware level stuff, the 30-60 seconds it takes to actually boot Linux up to a login prompt (especially w/o X setup for logins) is minimal.
No it doesn't. You need the X client libraries installed, but no X server needs to run on the server.
Correct. The X-server is effectively the "display side" of the equation - you'd run it on your desktop/laptop to connect to the 'client' (your Linux/Unix server).
Nobody in their right mind really wants to be running an X-*server* on their actual Linux/Unix server - usually the server doesn't even have a real display on it anyways (and it's been years since I've really looked, but all the datacentrer-type KVM stuff I've seen sucked at even handling 1024x768 for 100's of servers - although my 8-port KVM on my desk works ok for the 4 boxes I have hooked up to it - but monitor/cables/pc's are all within 8 feet of each other).
Slashdot Mirror
Is it sad that I've actually written VAX assembly before? Ah, college.
Sigh. VMS was such a nice operating system too in a lot of ways.
Of course I remember TOPS-20 too. And then there was that DG MV/8000.
I use XFCE as well.
XFCE 4.10 came out in April/2012. I'm honestly worried maybe things have stalled. I use Funtoo(/Gentoo) Linux, so I see from time to time things get updated in the various applications that make up XFCE, but I'm still worried about its future.
Just a simple question - if it works for you, unless there are some major security bugs or something, why does it matter if it gets 'updated'?
I've been in unix for over 20 years and never even heard of kill -1.
That's very honest of you. Don't know what you've been doing in Unix, but not knowing how to issue a SIGHUP signal (or why) after working with Unix for 20 years is not particularly a recommendation.
Probably best not to mention that on any future interviews.
To be honest, I've had to explain signals (in general) and SIGHUP to a lot of newbies over the years - it's certainly not something I would expect an *experienced* sysadmin not to know though, and if I was interviewing someone for a sysadmin job who supposedly had "20 years" experience and couldn't tell me at least a few of the *myriad* ways SIGHUP is used in unix - even if not explicitly by them issuing a 'kill -HUP' or 'kill -1' command (many daemons, etc), I probably wouldn't hire them.
I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?
Um, you "use" kill -1 *every* time you use "crontab -e", you also "use" it (the SIGHUP signal) for a lot of other things probably, like forcing apache httpd to re-read it's config file, or any number of other similar things where you can make an app/daemon re-read it's config. And if you drop your connection to your login shell without logging out first, it gets a SIGHUP as well.
It has nothing to do with linux/unix being 'unreliable'.
Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.
So you've never done a 'kill -HUP' in 20 years?
I would say the same thing, but there are several countries that can effectively impose their will anywhere within the Moon's orbit and a handful that could manage anything within the solar system. That said, having navigational control of a big rock on the edge of a gravity well may prove to be a hefty bargaining chip.
The Moon is a Harsh Mistress. :-P
I've used your analogy before. And USA law is that the USA corporation is legal obliged to instruct and take measures to get the data from the UK subsidiary. Nothing is changing here this has always been the case.
Which is, in effect, saying that MS then would have to take their UK subsidiary to a UK court to get a ruling, spending their own money taking themselves to court, in essence. That really should be for the US courts (prosecution) to take up with the UK court, shouldn't it? I mean, the whole concept of "me suing myself, and having to hire *both* prosecuting & defense attorneys" is ludicrous...
No, the evidence is not the property of a US company. The evidence is the property of a US citizen and is being held by a foreign subsidiary of a US company and is, therefore, exactly like the hotel example.
The world really would be simpler if we stopped trying to define how information on computer is the same as information on paper in some circumstances and different in others and just say that correspondence is correspondence, personal effects are personal effects, etc.
Which is, I would think, what MS is trying to do... get the courts to rule on it, one way or another, from the highest court possible.
NDAs are to cover technology or "trade secrets" - writing a review for "peppermint Coca-Cola" (making something up) saying "it sucks moose balls" isn't revealing their 'recipe' for making it or anything secret, anyone can buy a can and make their own judgement.
By the same token, even if I enter an NDA with a company to, say, integrate their technology into a product - saying "these people are a PITA to work with and I would never want to deal with them again" isn't violating the NDA on their technology.
Now... I could see perhaps if you entered into a deal with say Rossi and the "eCat" cold fusion nonsense, that saying "they're a fraud, the technology is a hoax" might perhaps be a gray area - but still, as long as you're not revealing their 'secret catalyst' or the actual (non-) functioning details of the device, you aren't really revealing their 'secret' technology?
The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
So you're "fixing" a bad application by changing the OS?
Apparently that's the "preferred solution" now... to me it seems to make far more sense to fix the application (BackupExec) to work the way it should, but that type of "logic" apparently doesn't apply to the systemd people who think that the "proper" way to fix that is to write a complex init system replacement and continue to allow people who write shitty service/daemon code to continue writing crappy code.
and rc.d it's so simple.
It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
Sounds like those issues are implementation based.
Yeah, sounds like some work needs to be done fixing the init scripts rather than writing a whole new init system to allow people to keep writing crappy scripts?
and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and.
Ok - well your talking about desktop stuff here, which is an interesting perspective that I didn't really consider, however I still think that is doable in inittab with much less effort. rc is only a runlevel solution, whereas inittab would be more relevant to desktop. I don't need to keep track of the process and it's children because init can maintain the parents state for me - if the parent isn't signalling it's children then we are back to implementation issues again.
Yup, instead of tackling the real problem - poorly written services - their "solution" is to try to write a new init system to allow crappily written services to be tracked/"controlled", ignoring the fact that the crappy modular services should be rewritten.
I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.
jeeez. I'm just trying to figure it out. I'm not being a jerk about it, I'm trying to gauge other peoples experiences. I don't give a fuck about init if systemd is better - it's just another technology. But if it is better than shouldn't it be immediately apparent *WHY* it is better?
Yeah, and I don't see as it "fixes" anything other than adding a lot more complexity to "fix" things that it shouldn't have anything to do with.
It could be argued that such things are simply not the responsibility of the init system. I think that is where much of the complaints about systemd come from, the perception that it is taking the roles of other things and folding them into itself. Given how it has been expanding to include more and more services and has increased coupling, they kinda have a point. Many see systemd as solving problems that are philosophical in the first place as opposed to practical.
"One ring to rule them all."
What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
It's not supposed to - a *properly* written service would/could/should keep track of it's own processes, that isn't something init was ever supposed to do (be the 'micro-manager' of everything). If run the rc script to stop a service, and it doesn't stop all the associated processes, that is *NOT* a "problem with init", that is a problem of a poorly written/debugged service, and the code for the service should be fixed - not a whole new massively complex init system to "handle" it (or, in simpler terms, to continue to allow the people writing services to write shitty code because now "systemd will handle it").
You'll also find that systemd is indeed quite unix-like......It's about consolidation of functions into one implementation
ok, you failed to understand the unix way
Bingo. Sums it up quite nicely.
You know that was a joke, right?
Daemonhostd is clearly a play on Windows Service Host.
Well, at least I HOPE it was a joke. With systemd, I'm not sure anymore.
You mean "daemonhostd.exe" right? ;)
Go tell that to the GNOME dev, who adopted systemd and now require it on all platforms running Gnome.
Why in God's name would you want to infect well designed OSs with Gnome?
That's unbelievably stupid.
I gave up on Gnome long ago.
That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1.
I will be clear that I am not a seasoned linux sysadmin; I know bits of Linux, I can manage a small installation, but Im definately not an expert. Im also not a seasoned programmer; I understand programming.
However I have had experience with a lot of badly written services on Linux where I've had to decipher the init scripts, or figure out why "service XX stop" doesnt actually stop the service, whatever stdout might claim.
It seems to me that the approach you are advocating works really well in a world where badly written services simply die out due to people rejecting them; in reality you have badly written services all over the place that get screwed up all the time. Your philosophy could be extended to say "we'll also have the kernel just manage cpu, disk, and memory, and leave handling the filesystem up to individual programs." Which works, as an engineering principle, but in the real world you will end up with filesystem corruption on a daily basis because you are causing the entire system to have a net increase in complexity.
From what Im gathering, systemd increases the base system complexity, but will (over time) ensure that those complex bits are stable (much like building FS support into the kernel). On the upside, it allows all of that complexity to be removed from all of the million other packages where 'building a stable init script" may have been priority 99 out of 100, and now they simply dont have to worry about that.
I see, so you are blaming the current minimalistic init process, that hasn't had any known/major bugs for decades really, for "badly written services all over the place"? Wouldn't that, instead, be something to push more for "better written services" about, rather than increasing the complexity of the init process?
Yes, as an *experienced* sysadmin (28yrs of Unix, from Edition7/earlyBSD to Linux/SysV, on everything from "big iron" to PC servers) I've seen poorly written start/stop scripts that don't do what they should, don't handle 'failure to stop' properly, etc. I've almost always been able to deal with it manually, in the rare cases it happened (HPOV was one of the worst, randomly left stuff running) I could fix it manually w/o a reboot, and if needed I could fix the script fairly easily (or submit a bug report to the vendor - even though they rarely fixed things like that very promptly). I certainly didn't blame the fact that some programs rc script was poorly written, or its processes were poorly written pieces of crap, on the init process. Under *any* Unix derivative I've worked on, well written services rarely needed a restart in the first place.
If the battery in your car dies, do you also launch an engineering team to redesign an entirely new car powered by a suitcase sized nuclear reactor, with all the increased danger that could involve if the 'unforeseen' happens, or do you just replace the faulty battery?
It may be an unpopular viewpoint, but this is why business is leery of the GPL and 3rd party contributions. Mojang should have been a little smarter before they acquired the toolkits and developers so they knew the ramifications of their purchase. At this point, it sounds like Mojang is being extorted since the code was never properly license in the first place.
Bingo. A lot of companies avoid GPL for just this reason.
You hit on one of the key words, "cleanroom". No code was contributed to Bukkit by people within Mojang with access to their internal repo. So the decompiled version is GPL while the internal version is not, thus no violation.
No, the decompiled version is still Mojang's code, it's not (and cannot) be GPL just because they decompiled it - any more than you could decompile a copy of MS Office, and say that the source to DecompiledOffice is now GPL.
They *stole* Mojang's MC code, in essence, by decompiling it and distributing it. Mojang was nice enough not to take them to court over it - but that doesn't mean the code is suddenly GPL.
(From GPL V3)
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
I would venture to say that the mod is not an "extension of a GPL3 covered work", in fact quite the reverse - it's an extension of a non-GPL work.
I don't see how the situation creates a GPL violation. It sounds, in fact, like the copyright that is violated is the copyright Mojang holds for Server, and Mojang has been kind enough to not press charges.
Sounds like it to me, they decompiled/reverse-engineered the Mojang *non-GPL* code, and Mojang was decent enough not to try to take them to court over revealing their own proprietary code. A lot of companies would have sued their butts off.
Right, the best way to prevent sophisticated American weapons from ending up in the hands of ISIS would have been to not hand them over to an incompetent sectarian asshat like Nouri Al-Maliki, the proper way to prevent that from becoming the only option would have been to not start a stupid war in Iraq to boost Halliburton stock prices, this in turn brings us to the most workable way to prevent America from starting a stupid war in Iraq in the first place which would have been to not elect a cheerleader for president.
Bill Hicks on George H.W. Bush & the military industrial complex
Especially in the server world. The OS boot time is a fraction of my server's boot process. Starting out, you've got POST with RAM tests et al. The RAID array spins up and does its dance. Maybe IPMI gets in the mix. The NICs might have their own prompt for configuration changes lasting a few seconds. And sometimes the BIOS decides to give a detailed list of events with a ten second countdown (bypassable with a keystroke). Then some particularly silly BIOSes complain for a few seconds about a lack of keyboard. Finally, the MBR is touched. systemd will never speed up the slowest part of the boot process, so it's useless for that purpose in a server environment.
Yeah, in all honestly OS boot time has never been an issue for me on startup - it's all the other stuff... the BIOS memory test on a 64GB machine, followed by by probing all the cards for their BIOS's and delays for disks to spin up, etc. When the machine takes 5 minutes to get past the BIOS/hardware level stuff, the 30-60 seconds it takes to actually boot Linux up to a login prompt (especially w/o X setup for logins) is minimal.
No it doesn't. You need the X client libraries installed, but no X server needs to run on the server.
Correct. The X-server is effectively the "display side" of the equation - you'd run it on your desktop/laptop to connect to the 'client' (your Linux/Unix server).
Nobody in their right mind really wants to be running an X-*server* on their actual Linux/Unix server - usually the server doesn't even have a real display on it anyways (and it's been years since I've really looked, but all the datacentrer-type KVM stuff I've seen sucked at even handling 1024x768 for 100's of servers - although my 8-port KVM on my desk works ok for the 4 boxes I have hooked up to it - but monitor/cables/pc's are all within 8 feet of each other).