People with large numbers of servers probably don't appreciate Linux becoming some sort of oddball or a precious snowflake.
I don't know. I'm assuming you mean POSIX since the other stuff in systemd is pretty specific to Linux configurations already. I'm not sure that POSIX really does matter. In the days of the OpenGroup certainly there were a huge range of Unixes all with moderate marketshare and thus horizontal compatibility was important to keep down development costs.
My feeling is the way this resolves is the BSDs develop a systemd emulation / compatibility sort of like an extended version of the shim and then mostly themselves move to something like systemd (likely a fork of launchd). But assume I'm wrong and that isn't what happens.
Today virtually all of the production servers (excluding embedded) are Linux. There exist plenty of non-systemd embedded distributions and that ecosystem doesn't currently seem threatened. So I'm not sure that breaking compatibility with the BSDs induces much cost. Moving to process management might decrease admin costs with respect to Solaris and AIX.
I would rather the "you lowly peons you don't have any clue, we run BILLIONS of servers" contingent just fucked off and used AIX instead.
I agree that this is being driven by the lack of viable good old fashioned industrial commercial Unix. Had Digital Unix, Solaris, AIX... really survived (i.e. kept up) then that would solve the problem. It is entirely possible that RedHat / Suse drive Linux to fill that void and it just is no longer suitable for smaller servers.
I can easily imagine that things keep going in this direction, an IaaS management suite becomes mandatory in distributions from say 2025 and you just can't boot an individual server at all under mainstream Linuxes. That is possible. But because of embedded there will still be classic Linuxes for simple servers. I just don't think they will be used much.
But the original question was about the vast majority of admins. I really think the issue is at admins who monitor dozens of boxes not tens of thousands. Those are the ones who often have the sorts of customization problems that make the systemd conversion nasty. But it is a one time cost. They will convert over to systemd and then convert over to one of the larger infrastructure management systems and not have to follow this nonsense themselves anymore.
Don't know. I do know there were some real problems for people with complex boot scripts. Those needed to be ported and now they are. One time annoyance.
Correct they do. What systemd standardization does is allows Linux applications to have a constant API to write against to get process management and thus as chunks of systemd get replaced by more complex PaaS components that API is how they talk to individual applications.
That's the benefit. Systemd sets a much higher minimum and a standard.
The Debian discussion was on this point. That's the citation. They figured they could hold out for Jessie but then what? The transition would be much rougher 2 years hence. As for the difficulty for early distributions like Arch and Fedora as contrasted with Debian, I think the debate makes a good citation.
It is their admins. Their admins are the ones who have to be able support process management infrastructures. Like I said I get that there are admins in who administer very traditional boxes for whom that is not true, but mostly they manage far less than thousands of boxes. The people managing those numbers had to make switch over for things like: virtualization, virtual networks, virtualized storage, SAN, clustering, distributed processing... which moved them away from classic 90s style admining.
, and somehow his software becomes the de facto standard in the Linux world
The somehow was his software is so useful that applications start to depend on its functionality and thus the distributions if they wanted to use current versions of software had not choice. POSIX when it came out was not 2 decades old. If something like the OpenGroup existed today PaaS functionality including process management (systemd) would be part of it.
The companies managing thousands of servers are some of the largest advocates for many of the key ideas of systemd especially process management. It is small admin managing small numbers of boxes with very old fashioned configurations that are having the biggest problems. This is not about managing tens of thousands of servers.
The NSA is an intelligence agency. The other intelligence agencies are used to and good at subverting foreign governments, companies and people.
Being foreign isn't going to help. It likely hurts. There are all sorts of laws that apply to RedHat restricted what intelligence agencies can do that wouldn't apply to some Finnish company.
If the transition was going to be smooth it would have been wheezy not Jessie. They waited and so it was bumpy Had they waited longer it would have been more bumpy.
As for not enforcing the need for sysvinit compatibility how did you want them to do that?
1) It acted as a good system admin language a better way to do what admins were doing with shell scripts 2) It solved the HTML forms problem via. CGI.
(2) has been replaced by JavaScript frameworks and other frameworks. (1) there is more competition and it is less important since admin GUI tools have gotten better. So it is less used but lots of people know it. It doesn't solve a problem people have today.
Perl6 OTOH brings a lot of functional ideas in. It will be ahead of Ruby, Python, JavaScript... conceptually. It won't be ahead of languages like Swift though. Whether that's enough at this point I don't know. Its been 20 years since Perl was the new kid on the block. Did it simply take so long that no one cares anymore? Can Perl6 catch up? Or do functional features matter so much that they create an opening. For example easy multithreaded shell scripts are at least concievable in Perl6. I suspect among admins, the original Perl1-4 crowd Perl6 thrives. I'm not sure what happens after that though.
Microsoft may not care because, as you say, I am probably not their target market, but that has nothing to do with it.
Of course it does. Saying product X doesn't work properly because it doesn't do use case Y for which is was never intended is fallacious. "This wine glass sucks because when I try and use it to hammer nails it shatters" is simply silly.
This is the sort of thing that Microsoft tends to say, and completely avoids a number of important points. What are you basing this determination on? I could believe the "uses more features" claim -- that can be measured -- but what about the "more effectively" claim? Whenever Microsoft says things like that, they're basing it on stuff like how many keystrokes/mouse clicks it takes to do something. That's a very poor measure of how effective users are, though.
The most common testing Microsoft does is giving experienced Office users a series of tasks often using features of Office that they aren't familiar with or necessarily even know exist. For example someone who frequently does PowerPoints may not know about transitions between slides, tell them to change the transition in a presentation. The level of success is then measured.
Prior to the ribbon, using menus, the typical Office user could complete 30% of those tasks successfully. With the first release of the ribbon it doubled and we are in the latest beta at 80%. That's a huge change in effectiveness.
They can also measure based on those tests how many of the tasks the typical users were able to complete immediately i.e. which ones they know how to do before taking the test. That number has gone up as well though not as much. They also look at time to complete simple tasks which is what you are talking about with the mouse clicks. That changes a bit with context sensitivity but the huge drop in effectiveness by that measure was moving away from keyboard shortcuts when people transitioned from WordPerfect.
You were using your personal experience, "I do this X, I do Y". That's not valid because you aren't the target market.
The people who use Office constantly most likely are able to use more features more effectively more often as a result of the ribbon. If they were to look at there 2003 documents and compare them to their 2013 documents they would see a difference. I'm not sure if you are pulling a valid sample or not, your typical Office user doesn't have strong opinions on computer issues and likely is easily led in the conversation towards and opinion depending on who they are speaking with.
People who need to stand and use a interface a tiny minority? Google's estimate on number of computer panels currently in all uses is 10b globally. If even.1% are being used for an extended period of time that's a substantial chunk of the market.
As for artist,s, architects... they come in around 2% of users. More than say developers.
Can you point me to a new input medium aside of keyboard and mouse that offers better control in a desktop environment?
Yes the digitizing pallet. That's been used by artists for a long time. It is also particularly important for people who need to operate laptops one handed, like workers who are standing.
I want a DESKTOP operating system. If something else works better on a tablet, do something else on a tablet. Simple as that. Even Apple was smart enough to know that one size fits all works in operating systems about as well as it does with underwear.
Microsoft has always believed in ubiquitous computing. That people want to run the same applications in different environments and not buy their applications over and over and over. It may be that Apple is right that people do want to do that, but I have trouble believing the same people who whine constantly about how much Windows upgrades cost really want to pay 4x over for the software.
What would make sense? You still open files. You still save them. And you still need to close them (or have some means of releasing locks on them so that they can be moved/copied/backed up/etc).
You don't open them anymore. You do a destructive overwrite not some sort of data append. So you don't need to close. Now if you think about, why do you save them? You already have the system regularly saving updates anyway, saving is cheap. Why bother with you saving? Instead maybe have something like marked versions.
This is, essentially, what an idea "Event Viewer" should be doing.
Exactly but it isn't quite that simple. Because you don't want to just view them you need to have a queue that passes messages back and forth. The human may want to pick between dozens of events and understand which ones are easy or important or time critical or...
When you're talking about a 55" TV, you're talking about what? SD Widescreen? HD? SHD? 4K? What? Resolution's the issue, not the device itself.
No... not at all. As pixels get physically bigger ratios have to change. For example the amount of white space between characters in a font increases much more slowly than the size of a character needs to increase. That is a 5 point font magnified 200% is not the same as the 10 point font. Resolution is not the only issue. DPI matters a great deal.
More important than that though is that size of screen determines how long a person will want to use it. Sligh increases in screen size induce drastic changes in willingness to engage for extended periods. So for example the average phone (4" screen) is 30 seconds. The average watch slightly more than a second. Average 15" screen is 1/2 hour.
But forcing everyone (including enterprise partners, where retaining costs MONEY), over to a new UI paradigm when there was nothing intrinsically wrong with the old one, is Just Fucking Stupid.
The rest of the post was about what was intrinsically wrong with the old one.
Face it. Standard desktop is 1-3 monitors, a keyboard, directional controller (mouse or mouse simulant (rollerball, touchpad, or joystick)), speakers and a microphone.
I don't have to face it because it is not true. Besides quibbling with whether microphone / speakers are really standard the big point is that work has been migrating away from desktop / laptops now for almost a decade. The form factors on which people want to work are shifting. So that's not standard. The work moves.
And there was DEFNITELY no reason behind applying that crap to Server 2012!
I do see the reason for mixed factor laptops like the Yoga or Surface. Microsoft traditionally wants the server GUI to be close to the desktop GUI to reduce training complexity. I don't think it goes beyond that.
What would be the upside of them letting you skip it? They want to provide web services they need an account. The same way as you needed a mouse in older versions.
Nobody would mind a better OS, but when the GUI has reached the pinnacle of usefulness, why try to force a change?
Because your assumption is way off. The GUI wasn't at a pinnacle. A few examples:
1) The file: open, save, close is really designed around a dual floppy paradigm. It makes no sense at all with SSD hardware. 2) As the number of system services require notification increase integrated notification handling becomes key 3) As device types become much more variable (ranging from a watch to a 55+" TV) graphics need to switch more readily 4) As input devices became more variable applications needed to take better advantage of them. etc...
Windows 7 was not a pinnacle. It did some things reasonable well on some particular types of hardware that were rapidly becoming less important and mainstream for an ever shrinking percentage of the population.
Continuum creates a continuum between desktop (windows 7) and Metro, integrating the two into a single GUI. That names makes sense.
Charms bar is a play on cntl-c to end where Win-C is used to bring up a bar to switch contexts (search web or change settings). At least the C makes sense.
Well of course the right way to do that would be to make the new style of icons mandatory. But forcing change through was the Windows 8.0 days. Microsoft chickened out with 8.1 and so now you get the half assed slow movement in a general direction kind of change.
Slashdot Mirror
I don't know. I'm assuming you mean POSIX since the other stuff in systemd is pretty specific to Linux configurations already. I'm not sure that POSIX really does matter. In the days of the OpenGroup certainly there were a huge range of Unixes all with moderate marketshare and thus horizontal compatibility was important to keep down development costs.
My feeling is the way this resolves is the BSDs develop a systemd emulation / compatibility sort of like an extended version of the shim and then mostly themselves move to something like systemd (likely a fork of launchd). But assume I'm wrong and that isn't what happens.
Today virtually all of the production servers (excluding embedded) are Linux. There exist plenty of non-systemd embedded distributions and that ecosystem doesn't currently seem threatened. So I'm not sure that breaking compatibility with the BSDs induces much cost. Moving to process management might decrease admin costs with respect to Solaris and AIX.
I agree that this is being driven by the lack of viable good old fashioned industrial commercial Unix. Had Digital Unix, Solaris, AIX... really survived (i.e. kept up) then that would solve the problem. It is entirely possible that RedHat / Suse drive Linux to fill that void and it just is no longer suitable for smaller servers.
I can easily imagine that things keep going in this direction, an IaaS management suite becomes mandatory in distributions from say 2025 and you just can't boot an individual server at all under mainstream Linuxes. That is possible. But because of embedded there will still be classic Linuxes for simple servers. I just don't think they will be used much.
But the original question was about the vast majority of admins. I really think the issue is at admins who monitor dozens of boxes not tens of thousands. Those are the ones who often have the sorts of customization problems that make the systemd conversion nasty. But it is a one time cost. They will convert over to systemd and then convert over to one of the larger infrastructure management systems and not have to follow this nonsense themselves anymore.
Don't know. I do know there were some real problems for people with complex boot scripts. Those needed to be ported and now they are. One time annoyance.
Correct they do. What systemd standardization does is allows Linux applications to have a constant API to write against to get process management and thus as chunks of systemd get replaced by more complex PaaS components that API is how they talk to individual applications.
That's the benefit. Systemd sets a much higher minimum and a standard.
The Debian discussion was on this point. That's the citation. They figured they could hold out for Jessie but then what? The transition would be much rougher 2 years hence. As for the difficulty for early distributions like Arch and Fedora as contrasted with Debian, I think the debate makes a good citation.
It is their admins. Their admins are the ones who have to be able support process management infrastructures. Like I said I get that there are admins in who administer very traditional boxes for whom that is not true, but mostly they manage far less than thousands of boxes. The people managing those numbers had to make switch over for things like: virtualization, virtual networks, virtualized storage, SAN, clustering, distributed processing... which moved them away from classic 90s style admining.
The somehow was his software is so useful that applications start to depend on its functionality and thus the distributions if they wanted to use current versions of software had not choice. POSIX when it came out was not 2 decades old. If something like the OpenGroup existed today PaaS functionality including process management (systemd) would be part of it.
The companies managing thousands of servers are some of the largest advocates for many of the key ideas of systemd especially process management. It is small admin managing small numbers of boxes with very old fashioned configurations that are having the biggest problems. This is not about managing tens of thousands of servers.
The NSA is an intelligence agency. The other intelligence agencies are used to and good at subverting foreign governments, companies and people.
Being foreign isn't going to help. It likely hurts. There are all sorts of laws that apply to RedHat restricted what intelligence agencies can do that wouldn't apply to some Finnish company.
If the transition was going to be smooth it would have been wheezy not Jessie. They waited and so it was bumpy Had they waited longer it would have been more bumpy.
As for not enforcing the need for sysvinit compatibility how did you want them to do that?
Perl solved 2 key problems:
1) It acted as a good system admin language a better way to do what admins were doing with shell scripts
2) It solved the HTML forms problem via. CGI.
(2) has been replaced by JavaScript frameworks and other frameworks. (1) there is more competition and it is less important since admin GUI tools have gotten better. So it is less used but lots of people know it. It doesn't solve a problem people have today.
Perl6 OTOH brings a lot of functional ideas in. It will be ahead of Ruby, Python, JavaScript... conceptually. It won't be ahead of languages like Swift though. Whether that's enough at this point I don't know. Its been 20 years since Perl was the new kid on the block. Did it simply take so long that no one cares anymore? Can Perl6 catch up? Or do functional features matter so much that they create an opening. For example easy multithreaded shell scripts are at least concievable in Perl6. I suspect among admins, the original Perl1-4 crowd Perl6 thrives. I'm not sure what happens after that though.
OK yeah that's what I meant. If you were just exploring then it works. If you want something specific just Google.
You likely are doing stuff that is harder now. There were pretty complex procedures a decade ago for many tasks.
I was talking about the exploration issue. If you were looking for something specific why not try help / Google?
What's preventing you from mousing over the ribbon to explore possible commands?
Of course it does. Saying product X doesn't work properly because it doesn't do use case Y for which is was never intended is fallacious. "This wine glass sucks because when I try and use it to hammer nails it shatters" is simply silly.
The most common testing Microsoft does is giving experienced Office users a series of tasks often using features of Office that they aren't familiar with or necessarily even know exist. For example someone who frequently does PowerPoints may not know about transitions between slides, tell them to change the transition in a presentation. The level of success is then measured.
Prior to the ribbon, using menus, the typical Office user could complete 30% of those tasks successfully. With the first release of the ribbon it doubled and we are in the latest beta at 80%. That's a huge change in effectiveness.
They can also measure based on those tests how many of the tasks the typical users were able to complete immediately i.e. which ones they know how to do before taking the test. That number has gone up as well though not as much. They also look at time to complete simple tasks which is what you are talking about with the mouse clicks. That changes a bit with context sensitivity but the huge drop in effectiveness by that measure was moving away from keyboard shortcuts when people transitioned from WordPerfect.
You were using your personal experience, "I do this X, I do Y". That's not valid because you aren't the target market.
The people who use Office constantly most likely are able to use more features more effectively more often as a result of the ribbon. If they were to look at there 2003 documents and compare them to their 2013 documents they would see a difference. I'm not sure if you are pulling a valid sample or not, your typical Office user doesn't have strong opinions on computer issues and likely is easily led in the conversation towards and opinion depending on who they are speaking with.
People who need to stand and use a interface a tiny minority? Google's estimate on number of computer panels currently in all uses is 10b globally. If even .1% are being used for an extended period of time that's a substantial chunk of the market.
As for artist,s, architects... they come in around 2% of users. More than say developers.
If you don't need to use Office much or a competitor you aren't the target market.
Assuming you aren't vision impaired
if you regularly use Office applications and have that problem do a training video.
Yes the digitizing pallet. That's been used by artists for a long time. It is also particularly important for people who need to operate laptops one handed, like workers who are standing.
Microsoft has always believed in ubiquitous computing. That people want to run the same applications in different environments and not buy their applications over and over and over. It may be that Apple is right that people do want to do that, but I have trouble believing the same people who whine constantly about how much Windows upgrades cost really want to pay 4x over for the software.
You don't open them anymore. You do a destructive overwrite not some sort of data append. So you don't need to close. Now if you think about, why do you save them? You already have the system regularly saving updates anyway, saving is cheap. Why bother with you saving? Instead maybe have something like marked versions.
Exactly but it isn't quite that simple. Because you don't want to just view them you need to have a queue that passes messages back and forth. The human may want to pick between dozens of events and understand which ones are easy or important or time critical or...
No... not at all. As pixels get physically bigger ratios have to change. For example the amount of white space between characters in a font increases much more slowly than the size of a character needs to increase. That is a 5 point font magnified 200% is not the same as the 10 point font. Resolution is not the only issue. DPI matters a great deal.
More important than that though is that size of screen determines how long a person will want to use it. Sligh increases in screen size induce drastic changes in willingness to engage for extended periods. So for example the average phone (4" screen) is 30 seconds. The average watch slightly more than a second. Average 15" screen is 1/2 hour.
The rest of the post was about what was intrinsically wrong with the old one.
I don't have to face it because it is not true. Besides quibbling with whether microphone / speakers are really standard the big point is that work has been migrating away from desktop / laptops now for almost a decade. The form factors on which people want to work are shifting. So that's not standard. The work moves.
I do see the reason for mixed factor laptops like the Yoga or Surface. Microsoft traditionally wants the server GUI to be close to the desktop GUI to reduce training complexity. I don't think it goes beyond that.
What would be the upside of them letting you skip it? They want to provide web services they need an account. The same way as you needed a mouse in older versions.
Because your assumption is way off. The GUI wasn't at a pinnacle. A few examples:
1) The file: open, save, close is really designed around a dual floppy paradigm. It makes no sense at all with SSD hardware.
2) As the number of system services require notification increase integrated notification handling becomes key
3) As device types become much more variable (ranging from a watch to a 55+" TV) graphics need to switch more readily
4) As input devices became more variable applications needed to take better advantage of them.
etc...
Windows 7 was not a pinnacle. It did some things reasonable well on some particular types of hardware that were rapidly becoming less important and mainstream for an ever shrinking percentage of the population.
That's what the Ribbon does, it hides based on context. Which means they can have more items not fewer.
Continuum creates a continuum between desktop (windows 7) and Metro, integrating the two into a single GUI. That names makes sense.
Charms bar is a play on cntl-c to end where Win-C is used to bring up a bar to switch contexts (search web or change settings). At least the C makes sense.
Well of course the right way to do that would be to make the new style of icons mandatory. But forcing change through was the Windows 8.0 days. Microsoft chickened out with 8.1 and so now you get the half assed slow movement in a general direction kind of change.