Without getting into personal anecdotes and non-disclosure material? That can get difficult.
A fast check of HP and Dell show that for roughly $4000, either can deliver a high end workstation with dual 256 GB flash drives, 10 Gig ethernet cards, top-of-the-line graphics cards, and 3.6 GHz quad-core CPU's. That''s a pretty effective definition for a modern graphics workstation.
Mythical or not, those old religious stories are at the foundation of much of Western society and cannot simply be ignored because they are not "rational". The ideas that a "chosen people" can and should engage in genocide, in wars of invasion, and even in the religious sacrifice of their own children is at the core of most modern civilizations. Even the Christians partake wholeheartedly in it, when their god "sacrificed his own sone for our sins".
If you're suggesting that a completely rational moral standard could not possibly include murdering children simply because it is rational, oh, my. A completely "rational" moral stance could be: "My culture is so superior that we can and should engage in wars of invasion to elevate others to our culture. And it is better to kill their young, especially the young men, lest they rise up in revolt and continue their struggle against our superior culture:" Such "rational" approaches include the Central African Repucllic now, Rwanan genocide, Kurdish genocide, Armenian genocide, and Jewish genocide of the last century, the genocide in North and South America since their discovery by Europe since the 15th century, and the history of most military powers since recorded history began.
I'm not suggesting it's moral, effective, or wise. I'm saying that it can be quite rational.
Since much of the advertisement content comes from a large but trackable number of hosted web servers and "content delivery networks" such as Akamai. Many of these web services have well defined URL's used to access their traffic, so quite a lot of filtering can be done by thoughtfully configuring proxies at the ISP, which need to handle and to cache this content anyway. The content stored in the proxy can also, itself be analyzed: HTTPS encryption doesn't help with avoiding that particular man-in-the-middle vulnerability.
The ISP's have big interest in this because _they_ pay for the bandwidth upstream, and for the infrastructure to handle that bandwidth. If they can deliver what their customers want without the relatively huge overhead of all the third-party advertising spew on web pages, I'm sure it's worth some thought and even some infrastructure to support this. And the advertisers are not their clients, their users are their clients. Most users would welcome halving or even eliminating most advertising, just as most television viewers welcomed the 'MyChoice' and the various DVR manufacturers including features to skip commercials.
I was careless: I actually meant a "Linux" workstation, not technically a "UNIX" workstation. I'm also rapidly approaching NDA material if I give out customer or partner names who use such hardware.
I'd look into what ILM, Industrial Lgiht and Magic, is using these days for their artists. Their switch from SGI based workastations to Intel hardware running Red Hat software was an exciting piece of technology news some years back.
The graphics workstations for special effects animations are still a very real market. They tend to have high end 10Gig, quite a lot of high speed RAM, flash drives for local processing, and very, very powerful video cards. They also used to have firewire for high bandwidth peripherals or external drives, but everyone's pretty much given up on that.
> Setting out to main and kill innocent people, including kids, for the sake of maiming and killing them, is not OK in any rational value system.
Have you ever studied the 10 plagues visited against the Egyptians for their slavery of the Jewish people? Especially the slaughter of every first-born Egyptian child? Or the sacrifice of his first born son by Abraham, the religious ancestor of Jewish, Christian, and Muslim religiouns? The list goes on and on. I'm afraid that slaughtering children for religious sacrifice, even innocent children to teach their parents a lesson, as a long cultural history.
That doesn't make it "rational", but it's certainly historically well founded.
I've done it, with children of various ages, in seminars, and with mentoring colleagues. Much like learning to cook or use a knife safely, almost _everyone_ can do the basics..
"STEM education" is not the same as "STEM": it's a specific subset, where the gender bias against women is overwhelmed by the predominance of women in education. Look at the top ranking faculty, positions with tenure and departmental leadership or board membership, and you see a very different ratio.
> Fact of the matter is, most people cannot do science.
Fact is, most people can do science. While few will have the tremendous insights of an Einstein, most people can observe, record, and _verify_ data, and especially note and report details that don't match the models they understand. That data gathering and verification, and that concern for data that does not fit the model, is a vital part of science that almost every human can participate in.
> Women with actual skills and insights have no problems in the sciences
Nonsense. There is a constant undercurrent in the hiring process of "what if she gets pregnant", even if such bias is outlawed in many states and even if it is never written into candidate review, much as "don't hire Americans, they cost too much" is not explicitly written into hiring policies. The bias is also demonstrated both statistically in overall hiring, and by numerous repetitions of the double blind experiment on scientific papers and job applications, such as:
They made the distinction, and I agree they used the wrong verb. Perhaps "pillage" would have been better, since they suggested that other galaxies are stealing the hydrogen fuel sources.
Even L1 and L2 lunar orbits are not that stable without attention. Solar forces, such as light pressure and solar wind, tend to destabilize them over time and require station keeping, especially as satellites have low mass and large solar panels.
There are other difficulties for satellites. The increased radiation of all types and even magnetic effects from the Van Allen belts can be very hard on circuitry. Adding shielding is very expensive, and over time even the shielding can become slightly radioactive itself. So I'd be very surprised indeed if any of our current satellites lasts even a single human generation.
More realistically, some chemical batteries, such as good lead-acid batteries in cool, dry climates will retain a slight charge for years. But they all have a notable self-discharge rate of at least a few percent a month. The notable exception among battery technologies seems to be this:
Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why, Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".
Allow me to restate your comment:
> Systemd will continue to work for Linux distros that don't care for stateless boot etc
Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities. OTher examples abound. For example, the new replacement for/etc/resolv.conf says at http://www.tin.org/bin/man.cgi...
Note that/run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from/etc/resolv.conf.
Who's going to maintain the symlink? If any sysadmin unsuspectingly edits that file directly and breaks the symlink, or exposes their system to puppet, cfengine, chef, or any other system tool that manages/etc/resolv.conf, does it break the link? And what restores the link if it's broken? If the link is broken, DHCP updates to/etc/resolv.conf will no longer be effectively published by the sytemd based DHCP client.
I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.
Until they publish a standard for the layout changes, they're winging it. There is no document that I can find that details the overall changes: it's all "read the code" or "I announced it on this mailing list that only a few people read".
Mountpoints for removable media are specified as going in "/media", not under "/run/l[whatever]/[userame]/media". While revising this now allows the attached to be mounted under a subdirectory belonging to a particular user and keeping other remotely connected users off the attached media, it creates additional complexities sharing that media. It can be made to work, but it destabilizes the path to the attached media.
For "/run", the FHS says : "This directory contains system information data describing the system since it was booted. . Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process." If the systemd authors were folowing the FHS, they'd have to delete the contents of/run on reboot. Not remount them: delete them.
This is one of the typical problems of systemd: they are really making up their own standards and practices on the fly, in violations of anyone else's existing standards. New approaches can be beneficial, but many of the consequences are unclear, and it's breaking stable system software, and existing standards, everywhere.
Unfortunately, systemd has elected not to work on top of the existing standards. It is breaking everyone else's stable tools though unexpected and unannounced modifications of basic layout.
Then they should have published a proposed FHS. They're making this stuff up on the fly: putting detachable mountpoints under "/run", for example, was quite confusing: I can name more instances if needful.
I missed the part where you mentioned "on top of", excuse me.
The part about how Java error logs tend to spew errors without any indexable reference means you have to add your own. That is, in fact, what Splunk does.
Because those databases bulk up, they get corrupted, and then _all_ logs are lost, not merely the specific utility's log file or particular time-stamped, rotated log file.
Been there, done that, had to help clean up the mess that a certified Splunk admin repeatedly made of the Splunk logs. He kept failing to realize that there are many distinct logs which have unique individual formats, and which can overwhelm the Splunk servers very quickly when they start spewing in erronesous states. This is especially of Java servers, which spew the java error codes without oranizable or easily indexed time stamps.
I can read almost anything _if I'm willing to invest the effort_. But it's another example of the "let's invent a new and unnecessary format, for no particular reason, that isn't compatible with any of the last few decades of stable, tested, robust tools". It also has _nothing_ to do with service or daemon management, which was the original reason that systemd was so widely acepted.
It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.
> A Stateless System goes one step further: a system like this never stores/etc or/var on persistent storage, but always comes up with pristine vendor state.
That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in/etc or persistent data in/var/lib. They're basically taking all the daemon specific parameters from/etc and putting them in/run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in/var/lib or configuration in/etc will have to be rewritten, including long-standing conventions such as/etc/hosts,/etc/resolv.conf, and/etc/nsswitch.conf.
Slashdot Mirror
Without getting into personal anecdotes and non-disclosure material? That can get difficult.
A fast check of HP and Dell show that for roughly $4000, either can deliver a high end workstation with dual 256 GB flash drives, 10 Gig ethernet cards, top-of-the-line graphics cards, and 3.6 GHz quad-core CPU's. That''s a pretty effective definition for a modern graphics workstation.
Mythical or not, those old religious stories are at the foundation of much of Western society and cannot simply be ignored because they are not "rational". The ideas that a "chosen people" can and should engage in genocide, in wars of invasion, and even in the religious sacrifice of their own children is at the core of most modern civilizations. Even the Christians partake wholeheartedly in it, when their god "sacrificed his own sone for our sins".
If you're suggesting that a completely rational moral standard could not possibly include murdering children simply because it is rational, oh, my. A completely "rational" moral stance could be: "My culture is so superior that we can and should engage in wars of invasion to elevate others to our culture. And it is better to kill their young, especially the young men, lest they rise up in revolt and continue their struggle against our superior culture:" Such "rational" approaches include the Central African Repucllic now, Rwanan genocide, Kurdish genocide, Armenian genocide, and Jewish genocide of the last century, the genocide in North and South America since their discovery by Europe since the 15th century, and the history of most military powers since recorded history began.
I'm not suggesting it's moral, effective, or wise. I'm saying that it can be quite rational.
Since much of the advertisement content comes from a large but trackable number of hosted web servers and "content delivery networks" such as Akamai. Many of these web services have well defined URL's used to access their traffic, so quite a lot of filtering can be done by thoughtfully configuring proxies at the ISP, which need to handle and to cache this content anyway. The content stored in the proxy can also, itself be analyzed: HTTPS encryption doesn't help with avoiding that particular man-in-the-middle vulnerability.
The ISP's have big interest in this because _they_ pay for the bandwidth upstream, and for the infrastructure to handle that bandwidth. If they can deliver what their customers want without the relatively huge overhead of all the third-party advertising spew on web pages, I'm sure it's worth some thought and even some infrastructure to support this. And the advertisers are not their clients, their users are their clients. Most users would welcome halving or even eliminating most advertising, just as most television viewers welcomed the 'MyChoice' and the various DVR manufacturers including features to skip commercials.
I was careless: I actually meant a "Linux" workstation, not technically a "UNIX" workstation. I'm also rapidly approaching NDA material if I give out customer or partner names who use such hardware.
I'd look into what ILM, Industrial Lgiht and Magic, is using these days for their artists. Their switch from SGI based workastations to Intel hardware running Red Hat software was an exciting piece of technology news some years back.
The graphics workstations for special effects animations are still a very real market. They tend to have high end 10Gig, quite a lot of high speed RAM, flash drives for local processing, and very, very powerful video cards. They also used to have firewire for high bandwidth peripherals or external drives, but everyone's pretty much given up on that.
> Setting out to main and kill innocent people, including kids, for the sake of maiming and killing them, is not OK in any rational value system.
Have you ever studied the 10 plagues visited against the Egyptians for their slavery of the Jewish people? Especially the slaughter of every first-born Egyptian child? Or the sacrifice of his first born son by Abraham, the religious ancestor of Jewish, Christian, and Muslim religiouns? The list goes on and on. I'm afraid that slaughtering children for religious sacrifice, even innocent children to teach their parents a lesson, as a long cultural history.
That doesn't make it "rational", but it's certainly historically well founded.
I've done it, with children of various ages, in seminars, and with mentoring colleagues. Much like learning to cook or use a knife safely, almost _everyone_ can do the basics..
"STEM education" is not the same as "STEM": it's a specific subset, where the gender bias against women is overwhelmed by the predominance of women in education. Look at the top ranking faculty, positions with tenure and departmental leadership or board membership, and you see a very different ratio.
> Fact of the matter is, most people cannot do science.
Fact is, most people can do science. While few will have the tremendous insights of an Einstein, most people can observe, record, and _verify_ data, and especially note and report details that don't match the models they understand. That data gathering and verification, and that concern for data that does not fit the model, is a vital part of science that almost every human can participate in.
> Women with actual skills and insights have no problems in the sciences
Nonsense. There is a constant undercurrent in the hiring process of "what if she gets pregnant", even if such bias is outlawed in many states and even if it is never written into candidate review, much as "don't hire Americans, they cost too much" is not explicitly written into hiring policies. The bias is also demonstrated both statistically in overall hiring, and by numerous repetitions of the double blind experiment on scientific papers and job applications, such as:
http://blogs.scientificamerica...
They made the distinction, and I agree they used the wrong verb. Perhaps "pillage" would have been better, since they suggested that other galaxies are stealing the hydrogen fuel sources.
If you can't read it in flat text, it's not long-term reliable documentatoin.
Even L1 and L2 lunar orbits are not that stable without attention. Solar forces, such as light pressure and solar wind, tend to destabilize them over time and require station keeping, especially as satellites have low mass and large solar panels.
There are other difficulties for satellites. The increased radiation of all types and even magnetic effects from the Van Allen belts can be very hard on circuitry. Adding shielding is very expensive, and over time even the shielding can become slightly radioactive itself. So I'd be very surprised indeed if any of our current satellites lasts even a single human generation.
The Volkswagen Beetle from the Woody Allen movie, "Sleeper"
http://www.tin.org/bin/man.cgi...
More realistically, some chemical batteries, such as good lead-acid batteries in cool, dry climates will retain a slight charge for years. But they all have a notable self-discharge rate of at least a few percent a month. The notable exception among battery technologies seems to be this:
http://en.wikipedia.org/wiki/O...
That device has been running off its battery, at an extremely low rate, since 1840. The bell is much softer now, but it shows no signs of failing.
Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why, Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".
Allow me to restate your comment:
> Systemd will continue to work for Linux distros that don't care for stateless boot etc
Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities. OTher examples abound. For example, the new replacement for /etc/resolv.conf says at http://www.tin.org/bin/man.cgi...
Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.
Who's going to maintain the symlink? If any sysadmin unsuspectingly edits that file directly and breaks the symlink, or exposes their system to puppet, cfengine, chef, or any other system tool that manages /etc/resolv.conf, does it break the link? And what restores the link if it's broken? If the link is broken, DHCP updates to /etc/resolv.conf will no longer be effectively published by the sytemd based DHCP client.
I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.
Until they publish a standard for the layout changes, they're winging it. There is no document that I can find that details the overall changes: it's all "read the code" or "I announced it on this mailing list that only a few people read".
I'm http://www.linuxbase.org/betas... open in front of me.
Mountpoints for removable media are specified as going in "/media", not under "/run/l[whatever]/[userame]/media". While revising this now allows the attached to be mounted under a subdirectory belonging to a particular user and keeping other remotely connected users off the attached media, it creates additional complexities sharing that media. It can be made to work, but it destabilizes the path to the attached media.
For "/run", the FHS says : "This directory contains system information data describing the system since it was booted. . Files under this directory must be cleared (removed or truncated as /run on reboot. Not remount them: delete them.
appropriate) at the beginning of the boot process." If the systemd authors were folowing the FHS, they'd have to delete the contents of
This is one of the typical problems of systemd: they are really making up their own standards and practices on the fly, in violations of anyone else's existing standards. New approaches can be beneficial, but many of the consequences are unclear, and it's breaking stable system software, and existing standards, everywhere.
> Millions of people around the world paying small amounts of money for iOS apps
Mostly, it shows that it can't be done. Most of them go bankrupt as soon as they try to scale beyond a few intrigued users.
Unfortunately, systemd has elected not to work on top of the existing standards. It is breaking everyone else's stable tools though unexpected and unannounced modifications of basic layout.
Then they should have published a proposed FHS. They're making this stuff up on the fly: putting detachable mountpoints under "/run", for example, was quite confusing: I can name more instances if needful.
I missed the part where you mentioned "on top of", excuse me.
The part about how Java error logs tend to spew errors without any indexable reference means you have to add your own. That is, in fact, what Splunk does.
Restarting the same daemon, insistently, without the userland opportunity to manually restart the daemon log or wrap it in a debugger.
Because those databases bulk up, they get corrupted, and then _all_ logs are lost, not merely the specific utility's log file or particular time-stamped, rotated log file.
Been there, done that, had to help clean up the mess that a certified Splunk admin repeatedly made of the Splunk logs. He kept failing to realize that there are many distinct logs which have unique individual formats, and which can overwhelm the Splunk servers very quickly when they start spewing in erronesous states. This is especially of Java servers, which spew the java error codes without oranizable or easily indexed time stamps.
I can read almost anything _if I'm willing to invest the effort_. But it's another example of the "let's invent a new and unnecessary format, for no particular reason, that isn't compatible with any of the last few decades of stable, tested, robust tools". It also has _nothing_ to do with service or daemon management, which was the original reason that systemd was so widely acepted.
It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.
Quoting from the b log at http://0pointer.net/blog/proje...
> A Stateless System goes one step further: a system like this never stores /etc or /var on persistent storage, but always comes up with pristine vendor state.
That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in /etc or persistent data in /var/lib. They're basically taking all the daemon specific parameters from /etc and putting them in /run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in /var/lib or configuration in /etc will have to be rewritten, including long-standing conventions such as /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf.