I'd feel the same way if they hadn't already released a working proof-of-concept. It's based on XenServer 7.2 while what they'll be working on will be based on 7.3. A good number of the stretch goals have been done by users on the side for one purpose or another at times or by folks inside the Xen project or involved with XenOrchestra as proofs-of-concept as well. For example, software RAID is fairly common in small lab settings for XenServer installations, one I've used myself.
I see, and what the annual rate for a voting individual?
I'm not sure, you'd have to ask Sir Tim how much he got for railroading this abomination through the process. Oh, wait, you're asking how much it costs to join, aren't you? No idea, I'm afraid.
Some more interesting timing: Apparently Jake's last day was two whole weeks ago, May 25th, and he was officially shown the door on the 27th. I'm not sure if it's true or not, but it's certainly interesting.
For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.
Mine is actually slower but not by a huge amount, somewhere between 5 and 10%, varying from one boot to the next. The shutdown is either quite a bit faster, enough so that I worry whether things are being shut down correctly, or a whole lot slower, with no rhyme or reason as to why or which one I'll get on any particular shutdown. Systemd's "improved" logging system is, of course, no use in figuring it out.
I would add that the main problem they seem to be solving is slow bootup times, which are slow because you can't run startup processes in parallel..
That was the original reason for systemd before they decided to start the feature bloat. The fact though is that you can run startup processes in parallel and could without systemd. SUSE linux was able to do this and did a good job of it long before they switched to systemd while still using standard init scripts. On my system, the switch from that to systemd actually _slowed_ my boot process by about 10% because systemd insists on waiting for things that don't need to be waited for. Through some careful tuning, I've managed to get that slowdown to about 4-5% but it's still slower than the old parallel-run init scripts were.
Well if you want to route onions around the internet, then, yeah, it's an ok router (hint: puree routes better than whole onions and onion soup is even better until you get to the crouton and cheese). I'm mainly looking for a better way to route data from my home network to my Internet connection though.
9/11 was the most spectacular win for the authoritarians, because they more or less kicked the foundations out from Western society, and have helped to create the worst form of surveillance state you can imagine.
FTFY
No, you didn't. You just made it say the same thing again.
I know of no other company that can piss away 5-6 years of R&D and then claim over and over that the inferior new stuff is so great. It's mind-blowing.
Since they're attacking using high frequency sound, maybe have the machine emit some random noise in the same spectrum using its sound hardware while encrypting or decrypting or performing key generation. Wouldn't something like that jam such an attack (at least from a distance; if someone got microphones into your hardware that might be a different story)?
Maybe the mouse house is doing this to get their hands on ILM and Skywalker Sound. We all know they're about the money and I'm betting those two generate quite a lot. Maybe new Star Wars movies were a condition of the deal, not the reason for it.
I'm not disappointed in a slower release cycle. It should improve the quality of each release.
I think so too. I've been using openSUSE since it was SuSE Linux Professional and, before that, just S.u.S.E. Linux. They had an approximately annual release schedule for the newer, pre-Novell, versions and didn't try to stuff in every single newest thing going. I like to think this gave them the time to make sure that the vast majority of what they did ship worked well.
Unfortunately, a combination of changing to the "me-too" scheduling of releases (IIRC, the original discussion of the release schedule was calling for 6-month releases so they could be just like Fedora; after an attempt or two to maintain that, they switched to the schedule they're on now) and turning it into a beta-test for unfinished and premature software (systemd, pulseaudio, KDE 4.0, and the disaster that was online updates starting in the 10.x versions) have really degraded the distribution from what it once was.
From what I can see this moved the emphasis from shipping a distribution with what I'd call good "fit and finish", a good selection of software almost all of which worked correctly, no nasty surprises in the base functionality of the OS, etc., to trying to ship to a schedule, ready or not and ignoring anything that didn't get them there. I know the majority of bug reports I've made in newer versions got marked "wont fix"; not "can't duplicate" or "working as designed", but "won't fix", i.e. "yes, we know about it and know that it's broken but won't do anything about it". Not a good sign for a distribution that had been previously known for its functionality and stability.
I'm hoping that this serves as a wake-up call to the developers and that the suggestions coolo and others in the discussion are making will get them back toward shipping a distribution that's closer to what the old SuSE Linux was known for. What I'm seeing in the discussion is looking good so far.
Slashdot Mirror
I'd feel the same way if they hadn't already released a working proof-of-concept. It's based on XenServer 7.2 while what they'll be working on will be based on 7.3. A good number of the stretch goals have been done by users on the side for one purpose or another at times or by folks inside the Xen project or involved with XenOrchestra as proofs-of-concept as well. For example, software RAID is fairly common in small lab settings for XenServer installations, one I've used myself.
Oracle buying Red Hat would be the best thing that ever happened to SuSE.
Actually, they seem to insist it's SUSE now, but I'll always think of them as S.u.S.E.
Anyone who interviews regularly knows that 75% of developers can't count to 11
Huh? That's not hard:
0
1
10
11
I see, and what the annual rate for a voting individual?
I'm not sure, you'd have to ask Sir Tim how much he got for railroading this abomination through the process. Oh, wait, you're asking how much it costs to join, aren't you? No idea, I'm afraid.
Some more interesting timing: Apparently Jake's last day was two whole weeks ago, May 25th, and he was officially shown the door on the 27th. I'm not sure if it's true or not, but it's certainly interesting.
Regardless of Jake's innocence or guilt, I find the timing on this to be very interesting: Just after a major change in management and before what appears to be an upcoming change in the TOR protocol. I'm hoping that's just coincidental.
It could still live on as an optional add-on, but focusing on making a really good browser is a great idea.
Yes, the problem is that they're making the current version of Firefox instead.
For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.
Mine is actually slower but not by a huge amount, somewhere between 5 and 10%, varying from one boot to the next. The shutdown is either quite a bit faster, enough so that I worry whether things are being shut down correctly, or a whole lot slower, with no rhyme or reason as to why or which one I'll get on any particular shutdown. Systemd's "improved" logging system is, of course, no use in figuring it out.
All other "things" in the systemd project (as opposed to the systemd daemon) are configurable as to whether they are used or not.
Indeed. Could you please point me to the section in the documentation on how to configure not to use journald?
MOD THIS UP!!
It also still doesn't do POTS dial-up, still a necessity in some environments.
Ummmm. This is November 2014. Where does that contract / funding stand now?
I would add that the main problem they seem to be solving is slow bootup times, which are slow because you can't run startup processes in parallel. .
That was the original reason for systemd before they decided to start the feature bloat. The fact though is that you can run startup processes in parallel and could without systemd. SUSE linux was able to do this and did a good job of it long before they switched to systemd while still using standard init scripts. On my system, the switch from that to systemd actually _slowed_ my boot process by about 10% because systemd insists on waiting for things that don't need to be waited for. Through some careful tuning, I've managed to get that slowdown to about 4-5% but it's still slower than the old parallel-run init scripts were.
I hear these onion routers are all the rage now.
Well if you want to route onions around the internet, then, yeah, it's an ok router (hint: puree routes better than whole onions and onion soup is even better until you get to the crouton and cheese). I'm mainly looking for a better way to route data from my home network to my Internet connection though.
9/11 was the most spectacular win for the authoritarians, because they more or less kicked the foundations out from Western society, and have helped to create the worst form of surveillance state you can imagine.
FTFY
No, you didn't. You just made it say the same thing again.
No, you can't; they already come that way from the factory.
Ooooo, I like this one. Who are these people and do they have any kind of formal organization? I want to join up....
I know of no other company that can piss away 5-6 years of R&D and then claim over and over that the inferior new stuff is so great. It's mind-blowing.
Microsoft?
Since they're attacking using high frequency sound, maybe have the machine emit some random noise in the same spectrum using its sound hardware while encrypting or decrypting or performing key generation. Wouldn't something like that jam such an attack (at least from a distance; if someone got microphones into your hardware that might be a different story)?
Now people are all neurotic about their DNA being obtained when it's the content of alchohol and drugs in their system they're checking.
And you're certain that's all that's being checked how, precisely?
I'm pretty sure you're wrong on both counts.
Maybe the mouse house is doing this to get their hands on ILM and Skywalker Sound. We all know they're about the money and I'm betting those two generate quite a lot. Maybe new Star Wars movies were a condition of the deal, not the reason for it.
Sounds like a network boot of Windows 95/98 + roaming profiles to me.
"boop"
I'm not disappointed in a slower release cycle. It should improve the quality of each release.
I think so too. I've been using openSUSE since it was SuSE Linux Professional and, before that, just S.u.S.E. Linux. They had an approximately annual release schedule for the newer, pre-Novell, versions and didn't try to stuff in every single newest thing going. I like to think this gave them the time to make sure that the vast majority of what they did ship worked well.
Unfortunately, a combination of changing to the "me-too" scheduling of releases (IIRC, the original discussion of the release schedule was calling for 6-month releases so they could be just like Fedora; after an attempt or two to maintain that, they switched to the schedule they're on now) and turning it into a beta-test for unfinished and premature software (systemd, pulseaudio, KDE 4.0, and the disaster that was online updates starting in the 10.x versions) have really degraded the distribution from what it once was.
From what I can see this moved the emphasis from shipping a distribution with what I'd call good "fit and finish", a good selection of software almost all of which worked correctly, no nasty surprises in the base functionality of the OS, etc., to trying to ship to a schedule, ready or not and ignoring anything that didn't get them there. I know the majority of bug reports I've made in newer versions got marked "wont fix"; not "can't duplicate" or "working as designed", but "won't fix", i.e. "yes, we know about it and know that it's broken but won't do anything about it". Not a good sign for a distribution that had been previously known for its functionality and stability.
I'm hoping that this serves as a wake-up call to the developers and that the suggestions coolo and others in the discussion are making will get them back toward shipping a distribution that's closer to what the old SuSE Linux was known for. What I'm seeing in the discussion is looking good so far.