I didn't say they would agree. I think I understand what they want and what they do get out of it, and don't agree with them. I don't call them idiots or anything, they have their perspective, I have mine. I see their points and will acknowledge and explain why my perspective doesn't agree with the value.
In this particular thread, there has been some people saying 'right on' and there have been some pretty angry sounding posts calling me a troll. There was a pretty level headed systemd advocate as well, so I guess not all of them are that way, just some of the most vociferous, but maybe that's just the nature of the beast in any discussion.
You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.
While there is a grain of truth, the rules are a bit more straightforward in SYSV. SYSV was created by people that were largely starting out and did KISS out of necessity. So one needed only to understand some relatively basic bourne shell and you could figure it out from there as needed, even if you didn't know it. In his example, environment variable fell out of the sky. In init script, you know it had to be set *SOMEWHERE* from that script. It sourced another file, bingo, there it is in plain text. There are some things in SYSV that are a little weird (runlevels being arbitrary numbers, but there's a handful of them and inittab was a relatively short file), but generally it was quite discoverable given relatively simplistic understand of shell scripting. In systemd, if the config files pan out right, then they are simpler than the SYSV scripts. When things go wrong beyond what the author had intended, sysadmin is less likely able to figure out what the developer did wrong and correct. This I think is the fundamental breaking point. systemd adds some features that I can't readily imagine being acheivable from shell scripts, but it's harder for a layman to dig into something that went wrong. This means software vendors can deliver more service automation and such more easily under something like systemd, so many software developers appreciate it. Sysadmins on the other hand cede the ability to be able to look under the hood themselves. It's a tricky walk.
more traditional systems have started to similarly fragment things, what with things like udev rules
udev is actually another beast that could use a lot of improvement, alongside DBUS. dbus, systemd and udev start straying from 'everything is a file' and start creating invisible constructs in a namespace that isn't really explorable. 'Everything is a file' sentiment has been lost. What people forget is that everything is a file really just means a pretty straightforward yet capable organizationed model that a client can explore. It's like RESTful in webservices are supposed to be (though that facet is also frequently unusable in some web frameworks, many do get it right).
Your results called out the Piledriver explicitly as 'per module' rather than 'per core' to make the numbers match. It basically validates the point you respond to. In practice, it's more complicated and can outshine hyperthreading in some cases, but in your specific citation the processor measures up if you pretend module==core rather than saying it is an 8 core system.
It means no such thing. You need to learn about spwan and fork, then get back to us.
That scenario doesn't involve the special nature of pid 1 at all. Any pid can screw up a system. Traditional init is a handful of lines of compiled code and systemd is significantly more to assure services cannot escape their cgroup and other such tricks.
. The kernel does not run " in an equally critical context" at all
If pid 1 crashes, the only thing I can really do is sysrq. The division between kernel space and user space pid 1 is largely academic for a sysadmin afflicted by a crashing bug in either one of them. Yes there are thnigs kernel c code can do beyond the reach of user space code, but that was really not the point of the discussion.
There is nothing more inherently complex about systemd than any other init system
If that were the case, why would systemd exist at all? Systemd exists because they wanted to pull off some tricks they couldn't do in an init system that could be followed by a simple 'set -x' in key locations. Like Windows, when things work, they appear simple enough on the surface. Like Windows when things go wrong, you are pretty well in a weird world.
Who cares? Do you really think it needs to be ported to Windows?
Do you really not acknowledge the existance of FreeBSD, NetBSD, OpenBSD, AIX, Solaris, HP-UX, and more?
If you like that old garbage, you are free to use it.
If the people who like straightforward init scripts don't bitch, then their preferences will go unheeded. It's better to bitch than be silent as your perspective is steamrolled out of the way. It's not 'old garbage' no more than the wheel is 'old garbage'. Just because something does the job and hasn't been mucked with in years does not mean it should be presumed garbage and replaced.
Well it does solve some problems, just not problems many server administrators largely cared about while creating problems some systems administrators really do care about.
-Services cannot reparent themselves out of the launching context, meaning init system *always* knows how many processes it is and resources it consumes. It's nice and structured, too bad that ps axf and grep largely serve the same purpose when things went south, but the systemd approach is certainly more structured. Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.
-Bake in more advanced log processing to mitigate the need for log analysis tools. The problem of course being that those log analysis tools tend to work well enough while leaving the plain text behind in a manner that can be trivially opened and perused in Windows or whatever.
-Starting up/bin/sh hundreds of times during boot is wasteful and slows boot. Systemd mitigates that by enabling more lightweight service start. However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.
-Sequential startup of services is silly when many can be started in parallel. Of course now you have to debug a less deterministic boot process to enable such a thing, with the same inscrutable code paths for the sake of a faster boot very few people needed.
The complaint about systemd is that it adds complexity to the base function of the OS, not that it fails to do what it advertises. It's not that people take issue with the way you deal with systemd, it's that when things don't go according to plan, it's a mess compared to the alternative.
For the services, you do have SysV for example still. You write one SysV script and systemd can make use of it just like the other init systems can.
What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
Init runs as PID 1. Systemd runs as PID 1.
Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.
Claiming that "lots of people don't like systemd equates to anything other than lots of people don't understand systemd, but will complain anyway is just stupid
No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).
Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well.
And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).
What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just th
On the other hand, hourly employees are generally held to 40 hour workweeks because they get expensive beyond that.
Frequently salaried individuals have their exempt status abused by making them work 60 or more hours a week. I personally am fortunate enough to not suffer this, but a lot of shops will burn out their coders with ever present threat of finding cheap replacements.
Hence why I compared it very carefully to IBM'S SMT rather than Hyperthreading. IBM SMT has componentsto handle each 'thread' while sharing common components (including FPU in SMT8 but isn't shared in SMT4). It isn't 8 threads in the hyperthreading sense, but neither is it 8 'cores' with respect to how any other CPU vendor calls things cores. IBM is the only other microprocessor vendor that has something that resembles the AMD design, and they do not refer to the components as 'cores'.
I haven't seen any FP intensive code work better than Ivy bridge equivalents (1 ivy bridge core =~ 1 piledriver module no matter what I tried with respect to running one or both of the 'cores'). Haswell of course can roughly double ivy bridge perf when avx2 can be put into optimal play.
AMD is sadly little more than a 'budget' player right now. Releasing inefficient designs to compete roughly with Intel. Though NetBurst was sadder, as you were expected to pay *more* for the crappy inefficient product than the rather good (for the time) Athlons. Here's hoping they get their stuff back.
Indeed, even after installing the software, upgrading is easy. Excepting some DRM crap that could fire if you change too much, but that is BS.
I am actually married and a father too. I can't disappear into a 'mancave' every day for hours on end or spend all our money on high end gaming equipment, but I don't catch flak for spending my time gaming for a short while many days and the occasional 'bender' of gaming. If I covered the house in gaming paraphernalia or something maybe, but as long as I don't go overboard on time or expense, there's no issue.
I'm not saying the IPC is netburst like, but that the overall performance characteristic is low performance relative to what the competition *would* be at '8 cores'. Just like a NetBurst 3.0 ghz would have been trounced by the contemperary AMD at 3.0 ghz (and even much lower), an '8 core' is bested by something with much lower core count. For example, in the url you cite, they effectively consider the FX 8350 as a quad core rather than 8 core solution for the performance to be comparable. This is with a workload that does not take advantage of AVX2 (which would have the Haswell parts pull well ahead of the competition). A quad core 4.1 ghz ivy bridge would have matched the '8 core' 4.1 ghz 8350. So if you get the '8 core' thinking 'twice as fast as ivy bridge quad core', that would be incorrect assumption that AMD is counting on marketing wise.
In short, AMD has '8 cores' that performs like 4 cores, but with heat and power characteristics more closely resembling 8 than 4 cores. Just like an Athlon at 2 ghz could match the performance of a Pentium 4 at 3 ghz, but with much less power/heat than the Pentium 4.
Why not actually try the games that you want and then decide if things are too slow at all, rather than listen to some people that will evangelize how cool new stuff is with impunity since it is not their money they are justifying spend on...
Also, my wife thinks a grown man playing computer games is a little bit pathetic, and I can't really argue with her,
What could be pathetic is neglecting responsibilities or pissing away family savings on superfluous stuff. If one takes care of their responsibilities appropriately and is prudent in their spending, it doesn't really matter if a grown man plays computer games or watch telly tubbies or whatever they like so long as it doesn't screw up other people's lives.
If IBM did the processor, they would have called it 4 Core with SMT2. Basically you have 4 modules, with 2 of many of the components, but a lot of shared components. Notably, each of the 4 modules has a single FPU (so it's more like IBM's SMT8 versus SMT4 mode if you talk about their current stuff).
So it's more substantial than hyperthreading, but at the same time not reasonable to call each chunk a 'core'. I think it behaves better than Bulldozer did at launch *if* you have the right platform updates to make the underlying OS schedule workload correctly, but it's still not going to work well (and some workloads work better if you mask one 'core' per module entirely).
Basically, it's actually pretty analogous to NetBurst. NetBurst came along to deliver higher clock speeds since that was the focus of marketing, with some hope of significant workloads behaving a certain way to smooth over the compromises NetBurst made to get there. the workloads didn't evolve that way and NetBurst was a power hungry beast that gave AMD a huge opportunity. Now replace high clock speed with high core count and you basically have Bulldozer/Piledriver in a nutshell. I'm hoping AMD comes back with an architecture that challenges Intel agin, just like Intel came back from NetBurst.
about Microsoft's ability to support Windows 9's expected rapid update pace."
I don't think this stuff is expected to go any faster. To be fair to microsoft, the frequency of updates is already pretty respectable (latency and quality on the other hand...). The rumors are that MS will start mixing in functional changes more. Of course this seems like a mistake, their competitors really aren't mixing it up much on the fundamental level anymore (Google churned pretty hard because they needed too, but Jelly Bean seems to have marked where they broke out the functcion).
Microsoft is only bested on the 'faster' (latency and frequency) front by Linux Desktop distros, and see how much that has made people in the wider market care. It's a shame because Android updates are pretty infrequent *and* get deployed extremely slowly. This means a great deal of mobile Chrome browsers continue to have SSL vulnerabilities, mitigated somewhat by most reputable servers having addressed it on their end. If MS was botching a security update that badly the community would be all over them. Though again, the wider market doesn't really care except to be pissed at having to deal with frequent update related interruptions (where again I think linux desktop distros seem to have the right balance of availability but not being so heavy handed).
I don't download that stuff, but as a netflix user who also has DVD rips and DVR recordings that I manage under XBMC, I can easily understand the appeal of having the content locally and in a form that can be integrated with media from other sources.
Netflix outages are frustrating. When it is up, sometimes I can't stream the best quality in real time. Sometimes the client has to be kicked in the head for no apparent reason to make it stream at all or stream the best reasonable quality. Any seeking takes a relatively long time, and won't seek with the same precision as xbmc will. It does an admirable job of a UI, but it's not my favorite. I wish the streaming service could be mated with third party applications better to allow more than just netflix's concepts of show organization and playback control to work with their content, as well as the ability to prebuffer the highest quality regardless of my current conditions. I also find it excessively wasteful if I feel like rewatching something and knowing it redownloads it every time, which is where I would like to jump to 'just buy the damn thing' were there a convenient legal option without DRM.
That all said, they still have a great deal better software experience than amazon prime...
a 4-U box with sixteen processors in it that a cloud provider could cost-justify
As virtualization became 'cool', people said 'look how many instances you can cram on these gigantic boxes'. This quickly became 'how many instances am I going to lose if this goes down' or 'how many do I have to live migrate to service this thing?'. The cost advantages of scale with a larger box are quickly offset by practical issues. As such, if you need that much memory in a single system, those sort of boxes are still very valued (in-memory databases and some particular sorts of modeling for example). If the workload naturally fits into more nodes of smaller size, it frequently makes sense to opt for the higher node count. There is of course different break points depending on judgement calls, but most places seem to think of two sockets as about the sweet spot.
But in general I agree with the sentiment. I do think comparing random whitebox with the big POWER boxes fails to capture the whole reality, but it's easy enough to note that alongside that random whitebox there are enterprise grade suppliers using the common architecture. A person able to slap together a whitebox x86 may not be as useful for business continuity on his own left to those decisions, but those same skillsets can be employed toward an enterprise solution while staying in the x86 family. POWER does not scale down yet, and that is one of IBM's missions. I'm skeptical they will succeed, but at least they acknowledge ecosystem as a key need.
It is a market segment that is seeing growth, and the hype machine has gone into overdrive under the assumption that anything that grows will grow indefinitely overtaking anything it conceivably could in its path.
The reality like all other times before is that it might get more adopted than it should before receding to the appropriate amount as it plateaus as the hype gets done. Thin clients have been around for ages even as the hype behind them has erupted and died out multiple times. They clearly have their role but it is clearly not the end-all, be-all that these companies bill it as.
The attack is more precise. Need to know precisely when to pop up the input form of interest. Sure this information could allow them to disambiguate the context so that a random memory change in a random app doesn't trigger a false positive. Of course the whole point was also to demonstrate how well they could do without any remotely suspicious permissions.
So in the OS side, at the very least it seems that an obvious indication of application focus change would go a long way toward making this seem not right.
On the application side, I think applications that are likely to get sensitive information should always display a consistent randomized watermark in their application. Let's say they make an 'always at the top' bar with two randomized words. With that, the sensitive input forms that try to be phished will look incorrect because the watermark suddenly changes.
As for I/O, you can pass through PCI devices in to the guest for pretty-much native networking performance.
Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.
It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.
In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.
Slashdot Mirror
I didn't say they would agree. I think I understand what they want and what they do get out of it, and don't agree with them. I don't call them idiots or anything, they have their perspective, I have mine. I see their points and will acknowledge and explain why my perspective doesn't agree with the value.
In this particular thread, there has been some people saying 'right on' and there have been some pretty angry sounding posts calling me a troll. There was a pretty level headed systemd advocate as well, so I guess not all of them are that way, just some of the most vociferous, but maybe that's just the nature of the beast in any discussion.
I do also want to say that your post is a credit to systemd advocacy. Level headed discussion of the issues rather than senseless ranting.
You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.
While there is a grain of truth, the rules are a bit more straightforward in SYSV. SYSV was created by people that were largely starting out and did KISS out of necessity. So one needed only to understand some relatively basic bourne shell and you could figure it out from there as needed, even if you didn't know it. In his example, environment variable fell out of the sky. In init script, you know it had to be set *SOMEWHERE* from that script. It sourced another file, bingo, there it is in plain text. There are some things in SYSV that are a little weird (runlevels being arbitrary numbers, but there's a handful of them and inittab was a relatively short file), but generally it was quite discoverable given relatively simplistic understand of shell scripting. In systemd, if the config files pan out right, then they are simpler than the SYSV scripts. When things go wrong beyond what the author had intended, sysadmin is less likely able to figure out what the developer did wrong and correct. This I think is the fundamental breaking point. systemd adds some features that I can't readily imagine being acheivable from shell scripts, but it's harder for a layman to dig into something that went wrong. This means software vendors can deliver more service automation and such more easily under something like systemd, so many software developers appreciate it. Sysadmins on the other hand cede the ability to be able to look under the hood themselves. It's a tricky walk.
more traditional systems have started to similarly fragment things, what with things like udev rules
udev is actually another beast that could use a lot of improvement, alongside DBUS. dbus, systemd and udev start straying from 'everything is a file' and start creating invisible constructs in a namespace that isn't really explorable. 'Everything is a file' sentiment has been lost. What people forget is that everything is a file really just means a pretty straightforward yet capable organizationed model that a client can explore. It's like RESTful in webservices are supposed to be (though that facet is also frequently unusable in some web frameworks, many do get it right).
Your results called out the Piledriver explicitly as 'per module' rather than 'per core' to make the numbers match. It basically validates the point you respond to. In practice, it's more complicated and can outshine hyperthreading in some cases, but in your specific citation the processor measures up if you pretend module==core rather than saying it is an 8 core system.
It means no such thing. You need to learn about spwan and fork, then get back to us.
That scenario doesn't involve the special nature of pid 1 at all. Any pid can screw up a system. Traditional init is a handful of lines of compiled code and systemd is significantly more to assure services cannot escape their cgroup and other such tricks.
. The kernel does not run " in an equally critical context" at all
If pid 1 crashes, the only thing I can really do is sysrq. The division between kernel space and user space pid 1 is largely academic for a sysadmin afflicted by a crashing bug in either one of them. Yes there are thnigs kernel c code can do beyond the reach of user space code, but that was really not the point of the discussion.
There is nothing more inherently complex about systemd than any other init system
If that were the case, why would systemd exist at all? Systemd exists because they wanted to pull off some tricks they couldn't do in an init system that could be followed by a simple 'set -x' in key locations. Like Windows, when things work, they appear simple enough on the surface. Like Windows when things go wrong, you are pretty well in a weird world.
Who cares? Do you really think it needs to be ported to Windows?
Do you really not acknowledge the existance of FreeBSD, NetBSD, OpenBSD, AIX, Solaris, HP-UX, and more?
If you like that old garbage, you are free to use it.
If the people who like straightforward init scripts don't bitch, then their preferences will go unheeded. It's better to bitch than be silent as your perspective is steamrolled out of the way. It's not 'old garbage' no more than the wheel is 'old garbage'. Just because something does the job and hasn't been mucked with in years does not mean it should be presumed garbage and replaced.
Well it does solve some problems, just not problems many server administrators largely cared about while creating problems some systems administrators really do care about.
-Services cannot reparent themselves out of the launching context, meaning init system *always* knows how many processes it is and resources it consumes. It's nice and structured, too bad that ps axf and grep largely serve the same purpose when things went south, but the systemd approach is certainly more structured. Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.
-Bake in more advanced log processing to mitigate the need for log analysis tools. The problem of course being that those log analysis tools tend to work well enough while leaving the plain text behind in a manner that can be trivially opened and perused in Windows or whatever.
-Starting up /bin/sh hundreds of times during boot is wasteful and slows boot. Systemd mitigates that by enabling more lightweight service start. However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.
-Sequential startup of services is silly when many can be started in parallel. Of course now you have to debug a less deterministic boot process to enable such a thing, with the same inscrutable code paths for the sake of a faster boot very few people needed.
The complaint about systemd is that it adds complexity to the base function of the OS, not that it fails to do what it advertises. It's not that people take issue with the way you deal with systemd, it's that when things don't go according to plan, it's a mess compared to the alternative.
For the services, you do have SysV for example still. You write one SysV script and systemd can make use of it just like the other init systems can.
What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
Init runs as PID 1. Systemd runs as PID 1.
Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.
Claiming that "lots of people don't like systemd equates to anything other than lots of people don't understand systemd, but will complain anyway is just stupid
No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).
Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well.
And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).
What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just th
On the other hand, hourly employees are generally held to 40 hour workweeks because they get expensive beyond that.
Frequently salaried individuals have their exempt status abused by making them work 60 or more hours a week. I personally am fortunate enough to not suffer this, but a lot of shops will burn out their coders with ever present threat of finding cheap replacements.
Hence why I compared it very carefully to IBM'S SMT rather than Hyperthreading. IBM SMT has componentsto handle each 'thread' while sharing common components (including FPU in SMT8 but isn't shared in SMT4). It isn't 8 threads in the hyperthreading sense, but neither is it 8 'cores' with respect to how any other CPU vendor calls things cores. IBM is the only other microprocessor vendor that has something that resembles the AMD design, and they do not refer to the components as 'cores'.
I haven't seen any FP intensive code work better than Ivy bridge equivalents (1 ivy bridge core =~ 1 piledriver module no matter what I tried with respect to running one or both of the 'cores'). Haswell of course can roughly double ivy bridge perf when avx2 can be put into optimal play.
AMD is sadly little more than a 'budget' player right now. Releasing inefficient designs to compete roughly with Intel. Though NetBurst was sadder, as you were expected to pay *more* for the crappy inefficient product than the rather good (for the time) Athlons. Here's hoping they get their stuff back.
Indeed, even after installing the software, upgrading is easy. Excepting some DRM crap that could fire if you change too much, but that is BS.
I am actually married and a father too. I can't disappear into a 'mancave' every day for hours on end or spend all our money on high end gaming equipment, but I don't catch flak for spending my time gaming for a short while many days and the occasional 'bender' of gaming. If I covered the house in gaming paraphernalia or something maybe, but as long as I don't go overboard on time or expense, there's no issue.
I'm not saying the IPC is netburst like, but that the overall performance characteristic is low performance relative to what the competition *would* be at '8 cores'. Just like a NetBurst 3.0 ghz would have been trounced by the contemperary AMD at 3.0 ghz (and even much lower), an '8 core' is bested by something with much lower core count. For example, in the url you cite, they effectively consider the FX 8350 as a quad core rather than 8 core solution for the performance to be comparable. This is with a workload that does not take advantage of AVX2 (which would have the Haswell parts pull well ahead of the competition). A quad core 4.1 ghz ivy bridge would have matched the '8 core' 4.1 ghz 8350. So if you get the '8 core' thinking 'twice as fast as ivy bridge quad core', that would be incorrect assumption that AMD is counting on marketing wise.
In short, AMD has '8 cores' that performs like 4 cores, but with heat and power characteristics more closely resembling 8 than 4 cores. Just like an Athlon at 2 ghz could match the performance of a Pentium 4 at 3 ghz, but with much less power/heat than the Pentium 4.
Why not actually try the games that you want and then decide if things are too slow at all, rather than listen to some people that will evangelize how cool new stuff is with impunity since it is not their money they are justifying spend on...
Also, my wife thinks a grown man playing computer games is a little bit pathetic, and I can't really argue with her,
What could be pathetic is neglecting responsibilities or pissing away family savings on superfluous stuff. If one takes care of their responsibilities appropriately and is prudent in their spending, it doesn't really matter if a grown man plays computer games or watch telly tubbies or whatever they like so long as it doesn't screw up other people's lives.
If IBM did the processor, they would have called it 4 Core with SMT2. Basically you have 4 modules, with 2 of many of the components, but a lot of shared components. Notably, each of the 4 modules has a single FPU (so it's more like IBM's SMT8 versus SMT4 mode if you talk about their current stuff).
So it's more substantial than hyperthreading, but at the same time not reasonable to call each chunk a 'core'. I think it behaves better than Bulldozer did at launch *if* you have the right platform updates to make the underlying OS schedule workload correctly, but it's still not going to work well (and some workloads work better if you mask one 'core' per module entirely).
Basically, it's actually pretty analogous to NetBurst. NetBurst came along to deliver higher clock speeds since that was the focus of marketing, with some hope of significant workloads behaving a certain way to smooth over the compromises NetBurst made to get there. the workloads didn't evolve that way and NetBurst was a power hungry beast that gave AMD a huge opportunity. Now replace high clock speed with high core count and you basically have Bulldozer/Piledriver in a nutshell. I'm hoping AMD comes back with an architecture that challenges Intel agin, just like Intel came back from NetBurst.
about Microsoft's ability to support Windows 9's expected rapid update pace."
I don't think this stuff is expected to go any faster. To be fair to microsoft, the frequency of updates is already pretty respectable (latency and quality on the other hand...). The rumors are that MS will start mixing in functional changes more. Of course this seems like a mistake, their competitors really aren't mixing it up much on the fundamental level anymore (Google churned pretty hard because they needed too, but Jelly Bean seems to have marked where they broke out the functcion).
Microsoft is only bested on the 'faster' (latency and frequency) front by Linux Desktop distros, and see how much that has made people in the wider market care. It's a shame because Android updates are pretty infrequent *and* get deployed extremely slowly. This means a great deal of mobile Chrome browsers continue to have SSL vulnerabilities, mitigated somewhat by most reputable servers having addressed it on their end. If MS was botching a security update that badly the community would be all over them. Though again, the wider market doesn't really care except to be pissed at having to deal with frequent update related interruptions (where again I think linux desktop distros seem to have the right balance of availability but not being so heavy handed).
I don't download that stuff, but as a netflix user who also has DVD rips and DVR recordings that I manage under XBMC, I can easily understand the appeal of having the content locally and in a form that can be integrated with media from other sources.
Netflix outages are frustrating. When it is up, sometimes I can't stream the best quality in real time. Sometimes the client has to be kicked in the head for no apparent reason to make it stream at all or stream the best reasonable quality. Any seeking takes a relatively long time, and won't seek with the same precision as xbmc will. It does an admirable job of a UI, but it's not my favorite. I wish the streaming service could be mated with third party applications better to allow more than just netflix's concepts of show organization and playback control to work with their content, as well as the ability to prebuffer the highest quality regardless of my current conditions. I also find it excessively wasteful if I feel like rewatching something and knowing it redownloads it every time, which is where I would like to jump to 'just buy the damn thing' were there a convenient legal option without DRM.
That all said, they still have a great deal better software experience than amazon prime...
I had pretty much given up all hopes of DRM-free video via legitimate channels, even as music is pretty much DRM-free exclusively.
I'm not getting my hopes too much, but like DRM-free music before it, I'll be very eager to give them my money instead of buying DVDs with it.
I'm however fully expecting like eBooks, the DRM-free selection will remain sad and pathetic.
a 4-U box with sixteen processors in it that a cloud provider could cost-justify
As virtualization became 'cool', people said 'look how many instances you can cram on these gigantic boxes'. This quickly became 'how many instances am I going to lose if this goes down' or 'how many do I have to live migrate to service this thing?'. The cost advantages of scale with a larger box are quickly offset by practical issues. As such, if you need that much memory in a single system, those sort of boxes are still very valued (in-memory databases and some particular sorts of modeling for example). If the workload naturally fits into more nodes of smaller size, it frequently makes sense to opt for the higher node count. There is of course different break points depending on judgement calls, but most places seem to think of two sockets as about the sweet spot.
SmartOS reports eight processors
So you have a quad-core with hyperthreading.
But in general I agree with the sentiment. I do think comparing random whitebox with the big POWER boxes fails to capture the whole reality, but it's easy enough to note that alongside that random whitebox there are enterprise grade suppliers using the common architecture. A person able to slap together a whitebox x86 may not be as useful for business continuity on his own left to those decisions, but those same skillsets can be employed toward an enterprise solution while staying in the x86 family. POWER does not scale down yet, and that is one of IBM's missions. I'm skeptical they will succeed, but at least they acknowledge ecosystem as a key need.
It is a market segment that is seeing growth, and the hype machine has gone into overdrive under the assumption that anything that grows will grow indefinitely overtaking anything it conceivably could in its path.
The reality like all other times before is that it might get more adopted than it should before receding to the appropriate amount as it plateaus as the hype gets done. Thin clients have been around for ages even as the hype behind them has erupted and died out multiple times. They clearly have their role but it is clearly not the end-all, be-all that these companies bill it as.
The attack is more precise. Need to know precisely when to pop up the input form of interest. Sure this information could allow them to disambiguate the context so that a random memory change in a random app doesn't trigger a false positive. Of course the whole point was also to demonstrate how well they could do without any remotely suspicious permissions.
So in the OS side, at the very least it seems that an obvious indication of application focus change would go a long way toward making this seem not right.
On the application side, I think applications that are likely to get sensitive information should always display a consistent randomized watermark in their application. Let's say they make an 'always at the top' bar with two randomized words. With that, the sensitive input forms that try to be phished will look incorrect because the watermark suddenly changes.
As for I/O, you can pass through PCI devices in to the guest for pretty-much native networking performance.
Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.
It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.
In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.