Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.
That's a very interesting analogy, since I'm currently in a Japanese hotel overlooking a construction site.
Rather than the typical cinder blocks, the bottom two floors are being built from large reinforced concrete slabs, about 1 meter by 3 meters, which interlock and periodically have apparently-plastic pieces. It definitely has increased the speed of construction over laying cinder blocks, and I suspect the slabs and plastic provide some means of safety in an earthquake.
Elsewhere on the technological spectrum, several years ago I volunteered in Africa, where buildings were built with more traditional cinder blocks. The blocks, though, were formed with poor-quality cement, and crumbled when put under load. In America in the 1980s, I was involved in a remodeling project that had to replace some 50-year-old blocks because they were falling apart. Modern blocks (30 years ago) have much more consistent quality, because manufacturers can now chemically test the quality of cement before using it.
In short, construction techniques and technology have indeed improved in the last century. Not even the traditional block dimensions are "fine" for all cases, as I see across the street, though in other areas compatibility is necessary. The requirements have changed, but you seem blissfully unaware. Fortunately, your ignorance of technological progress does not negate its existence.
You're reading far too much into one word. You should try reading the rest of that paragraph.
The first init systems were damned little more than just a shell. After that, we moved to running a single script at startup, and eventually went to runlevels with some common conventions. That's where development stagnated for a decade or two, and that's where I'm drawing my "antique" line. At the time, systems couldn't handle multitasking very well (mostly in terms of race conditions and programmers' sanity), and the massive university systems didn't really need to boot quickly, either, so there wasn't much development in parallel initialization.
Since then, Linux has been created and moved to the desktop, and we have a whole slew of new init systems, most of which natively support modern perceptions of parallelism, security, configuration, hardware, and other new developments since their predecessors moved out of the design phase. It isn't so much that "old is bad" as that the new is more likely to have been designed with modern paradigms in mind. Despite your dismissal, parallelism in particular is important, especially as Linux has taken a role as the embedded OS of choice for smart devices and cheap laptops.
While "change for the sake of change" may be wasted effort, it must be compared against the effort of keeping the old system. For example, how much effort is required of a distro maintainer to write and maintain init scripts for all their packages, including functionality for checking that dependencies started correctly and that scripts follow current best practices? How much effort is required to even make sure that the scripts are numbered in order to start correctly? In an age where building a dependency tree is only a few milliseconds of work, I would say it is wasted effort to make a sysadmin figure it out.
On the side of systemd proponents, I don't think the argument has ever been that "old means bad". Rather, the argument has been that we've learned a few lessons over the past thirty years, and we ought to put those lessons into our software.
So let me get this straight... in order to say "Foo depends on some kind of bar, which happens to be baz on this system", I need to write a "bar" definition that actually runs "baz", and go modify a completely separate dependency file to add "foo".
In the effort to make an "apples to apples" comparison, it uses only the bare minimum of functionality from each toolset. There's no illustration of dependencies or capability control. It is useful for getting a rough idea of how the init systems' config files look, but not really as the basis for any kind of comparison, especially with regard to advanced features.
Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.
A fair point.
The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place.
Typically sysvinit or mostly-compatible equvalents. From my perspective, they don't want to learn something new, and they don't see the existing system as broken.
And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case?
The obligatory XKCD applies. Most boot processes are fast enough now that it's not really worthwhile for an end user to shave a few seconds off the time. On the other hand, doing something as a hobbyist is entirely about wasting time, so I won't hold that against you.
The biggest improvement over antique boot systems is going to parallel boot chains. Rather than running scripts one at a time, in order, a tree is built to determine what services are dependent on what other services. For example, it doesn't make sense to start the SSH server until the network is live. There are several init systems that do this, differing mostly in how they define dependencies. Some rely on specific services ("openssh-server relies on network") while others work on more generic capabilities ("remote-shell relies on network, and openssh-server is what we'll use for remote-shell").
After parallelism, it gets tricky and subtle. Maybe we don't need all of a service to start before its dependencies. For example, we don't necessarily need all of our DHCP leases assigned before we know which network interfaces are connected. That requires a more granular service definition, but provides a lot more power, especially for systems with very complicated startup procedures. With that power, we can shave a few more seconds off the boot time, because we aren't required to wait while services settle, improving our overall parallelism. That's useful for me (professionally, I build systems that boot with a strict time limit, and may reboot every few hours), but most folks don't really benefit with the added complexity.
Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.
I don't know much about Android init, but I think it uses its own system unrelated to systemd, sysvinit, or any of the alternatives listed in TFS.
I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
That's always been the standard method in this country. We've had the Boston Tea Party, anti-slavery protests, Black Panthers, Vietnam, Rodney King... and now we yell about pipelines and drilling, elections, foreign policy, and who can use what restrooms.
That said, there is still room for facts and consideration by those who are actually doing the work, and that's encouraging. I've been involved with a number of activist programs hosted by those "elites" who know what they're talking about. It's provided me a very interesting perspective on how complex the typical analysis really is.
Fortunately, the loud voices don't seem to have much effect on the people who are actually affect policy... Unfortunately, the loud protests do distract from those folks, creating the appearance that nothing is being done, leading to further dissatisfaction. There has always been, and will always be, a certain fascination with the folks who complain loudly and reduce complex situations to a simple cause. There are roughly 7 billion people on this planet, and that's about 500,000,000,000,000,000,000 relationships. "Simple" is not a word that applies easily.
It's also very disappointing that the polls and predictions were so wildly incorrect. That is highly irregular, though not indicative of foul play.
I'm not ambitious enough to find the article, but Nate Silver had an informative retrospective piece about how some of the most influential voting blocks ended up voting contrary to what they were assumed to do, while polls concentrated on getting accurate results in other areas more typically "on the fence".
Trump's campaign did a surprisingly good job of swaying typically-blue voters to his side, while Clinton's campaign focused on the traditional swing states. Ultimately, those states that Clinton won couldn't compensate for the masses that Trump won, so Trump won the election. Since the polls focused on those swing states as well, Clinton showed a lead there.
In the future, we'll need to have an analysis of the polls that considers their assumptions about who's important to poll. The reality is that every vote counts, even when you might not expect it to.
Having read earlier reports of this analysis, I'm going to have to respectfully disagree.
From what I read, there was no attempt to find other explanations, like a demographic preference for e-voting over paper, or the local economic costs of maintaining one particular voting mechanism.
Nope, let's just just straight to assuming hacking.
Having worked in theater for a while, I can assure you that ticket sales (in a traditional venue, at least) have practically nothing to do with the house costs... but it's complicated.
First, the house charges rent. That typically covers the wear & tear, upkeep, and basic services for the show during its run. There may be basic crew costs included, or they may be negotiated separately, but the bottom line is a big up-front cost for the producers to put a show on stage at all.
As tickets go on sale, they are priced according to what the market will bear, through a joint agreement between the producers and the house. Front-row seats for a Broadway show pull in above-average prices, but the nosebleed section behind a pillar next to the air conditioner barely sells for enough to cover the processing cost. However, selling cheap seats allows the producers to boast about the number of tickets sold, and helps the house meet goals for community access (which is very important for nonprofit houses). A cut of the ticket sales goes to the house (justified as covering the box office processing costs), but the majority of it goes to the producers... After all, the producers are also paying a lot of the expense to promote the show, often through separate advertising deals with the house company.
To address the original point: Ticket sales are based on the market, not the expenses. A nonprofit house working toward promoting the arts might indeed sell tickets at a huge loss to please their patron donors. A promoter trying to increase a band's popularity might cut prices, expecting to lose money on the whole show in an effort to boost popularity for higher return later. On the other hand, a top-bill show with great reviews in other venues could be priced at a huge profit, and still expect to sell.
Finally, once the show opens, the producers have the captive audience in the seats, excited about the show, and that's when the real money-making starts. Concessions are usually handled mostly by the house, but merchandise is usually purely profit for the producers. That's why the adage about merchandise rings true. It does allow promoters to cut ticket prices and still make a profit on the show, or at least reduce the expense they paid for promoting the brand. For small bands who have to pay their own expenses, this is the best chance they get at turning a profit on the show.
While the OP did indeed ask for practical propulsion applications, the implications of a change in physics theory is enormous, as his example illustrates quite well.
Spectral lines led to the realization that energy is not continuous, but discrete in very small units which can interact with matter, and by inverting that principle, small changes to matter can result in large changes to energy. That directly led to the theory behind semiconductors, enabling transistors and other solid-state electronics, ultimately leading to the entirety of modern electronics technology.
Similarly, verifying a repeatable violation of the laws of physics means that those laws are inaccurate. By refining the theory to fit the new observations, we can also revisit our assumptions about what is possible using electromechanics. To address OP's question, energy, not fuel, becomes the limiting factor in propulsion. That in turn alters the theory of rocketry, which affects the limits of human expansion, providing new areas of study for anthropology and sociology.
However, the scope of affect also lies beyond rocketry. If EM can produce thrust, we may be able to miniaturize the device to a nanotechnology scale, as a new tool for nanomachines. As one example off the top of my head, we may be able to produce self-controlled materials that change shape by rearranging microscopic structures, similar to how animal muscles work by moving actin and myosin molecules.
In short, the actual application of any discovery is the increase in understanding of how the universe works, and from that we can derive advances in technologies.
"Wrong" and "illegal" are two different things. Despite what certain politicians may say, the American judicial system is built to ensure that only people who do illegal things go to jail. I'm not saying it works perfectly at making sure people who don't do illegal things stay out of jail, but that's another discussion. What's important in this case is that we don't just decide "this person ought to be in jail", and invent retroactive mechanisms to imprison them.
First it starts with having an understanding of what's going on. Then it continues with realizing that an assumption isn't necessarily true, and finishes with finding a means to force that assumption to be invalid.
One of my favorite exploits is a privilege-escalation issue on very old Linux systems. In short, you run a program that crashes and drops raw memory into cron's job folder, and when cron looks at the dump, it sees something that looks like a job spec, so cron happily runs whatever was in that memory dump, as root.
This exploit existed because Linux would assume that dropping a file would always be a safe thing to do, while cron assumed that only root would be able to drop files in its job folder. Together, they made a vulnerability.
There's a very good chance that I'm remembering it incorrectly as 3G, when really it's supposed to be 2G. It's been a very long time since it affected me enough to care.
T-Mobile's "unlimited" plans are what I use, and they've always been pretty straightforward about what that means... They don't hit you with a hard-stop limit, but after a particular chunk of full-speed data, they cut you back to "3G speed". All of their marketing material that's I've paid attention to has stated that plainly (to an engineer), in print that wasn't particularly small.
I can't say I've ever found the advertisements to be particularly misleading (or the policy to be particularly limiting), but I'm not as touchy as some consumers are, I guess.
No. HFT is legitimate buying and selling, just done at high speed. An order goes through, ownership is transferred... everything you'd expect from a legitimate business, just executed very quickly. What's different here is that this guy allegedly posted transaction orders just long enough to affect market prices, then canceling them, capitalizing on the price fluctuations with separate legitimate trades.
Cancelling orders is a protection mechanism for accidentally making stupid orders, like putting an extra digit in the price. When exploited to significantly alter the market, it's a bad-faith contract, which is generally illegal in most countries, though the particular codified law varies wildly.
It's always Russia, because we still haven't definitively settled the dick-measuring contest left over from World War II. It's hard to measure while the two main contestants (and new challenger China) keep simultaneously participating in pissing contests and counting notches after fucking other countries.
The metaphor's getting a bit strained, but the bottom line is that it's a mess that hasn't been resolved in the last century. America was doing great in the 20's, horribly in the 30's, then somewhat stabilized after WWII. Meanwhile, Russia was doing decently in the 20s, badly oppressed in the 30s, then pretty unstable (but pretending otherwise) after WWII until the Soviet Union collapsed in 1991. After that, there have been several factions fighting for power, and one of the more aggressive factions has taken control, now looking to solidify Russia as the main superpower of the world.
Then, of course, there are all of Russia's allies that have caches of Soviet weapons, and the ongoing corruption that allows them to get more. Even if "hurt America" weren't Russia's intent, there's enough belligerence in Russia's government that most conflicts can be traced back to some Russian office.
On the American side, we've done little to discourage such saber-rattling. In a burst of benevolence, we've helped overthrow oppressive government regimes, only to be pulled back by our own isolationist factions, leaving a power vacuum that attracts more oppressive dictators. We also tend to be vindictive, highlighting the Russian connections when a bad guy gets a delivery of shiny new weapons.
It's all very complicated, and has several symptoms of an ongoing cold war. Russia makes a public affair about our insecure elections, we make a public affair about their corrupt government. We build new weapons that could threaten Russia, they steal designs and threaten us. It's a stupid dance, and this is just another turn.
But it is being used to collect data on domestic targets which puts it in breach regardless of how many foreigners it's used on/for.
Actually, the case in question was apparently a group of foreign individuals who would always identify their messages with a particular signature phrase, described as "highly unique" to the group in question.
Yahoo was directed to capture only messages that matched that signature, and turn those over to the government, resulting in a high probability that only the foreign targets' messages would be collected by the investigators. That high probability, even if imperfect, is good enough to pass any legal or ethics review, because the investigation is actively trying to comply fully with the law.
After writing the famous "Go to statement considered harmful" essay, Dijkstra himself soon recanted, and clarified that there are particular circumstances where GO TO is the most straightforward solution, and results in the most readable and maintainable code. Of course, by then it had already developed such a stigma that there are now languages lacking such a construct, and those particular circumstances are now written with uglier and more confusing code.
It appears BUG_ON() is similar... There is a correct way to use it, that results in useful testing, perhaps better than any other method. Removing it completely may very well be a case where the cure is worse than the disease.
...or so you hope. Unfortunately, I've worked with enough doctors who just don't care that I won't accept that as a blanket statement for the entire profession.
...all I'm proposing is an extension of the increasingly popular concept to any informed patient.
But now you have to define what an "informed patient" is. I've also worked with enough patients who spent too much time with WebMD to accept that people can be well-informed just by reading a few articles on what they think applies to them.
...products labeled "FDA Approved" will be worth, on the average, more...
As long as that label is honest and respected, sure... but there's nothing to stop a fly-by-night operation from selling a drug with a not-quite-approval label and unscrupulously allowing doctors and patients to interpret the labeling (and marketing) as though it were actually approved. That, in turn, dilutes the FDA approval process, because if you can sell your drug enough to become standard without the hassle of approval, why bother? Do you actively check for a UL label on all of your electronics?
I hate to appeal to emotion, but the consequence here is literally peoples' lives. If it costs more to go through the FDA testing process, but saves the lives of people who would have been misinformed, is it worth the price? Conversely, do people deserve to die because they misunderstood the risks?
init starts and stops processes to attain different run levels. That's it. Period, the end. One small tool, which does one thing correctly.
I'm a bit more familiar with the program than my sarcastic post let on. Originally, init's job was to be the first process, period. It'd launch a shell, which quickly became "launch a login prompt" and then changed to "launch a bunch of services" and finally "launch everything the user wants to run for this runlevel". In short, to answer the original request, running getty is just about all you need.
There is nothing whatsoever magical about getty. It is extremely straightforward. It is one small tool, which does one thing correctly.
Relax; it's literary exaggeration. Once upon a time, as I recall, getty would manage its own tty connections. Now it takes a parameter so you can tell it to connect to a given device. If you want init to support multiple ttys right from the start, you'll want that feature.
There is no reason to use anything more (or less!) than a script for configuring networking. Scripting is a central feature of Unix.
Anything you can do in a script can be done manually. Isn't that the whole point of having non-compiled scripts in the first place?
My Debian system has 57 init scripts. If that kind of complexity scares you, perhaps computers are not for you.
Mine has 96, averaging 120 lines per script. I never said it scares me. I'm merely making fun of the aversion to Systemd's complexity, by highlighting the fact that you already have such complexity, but it's pushed out and duplicated (usually poorly) in your init scripts.
Yep. Using central Unix features like linking is the right way to do this. It utilizes the database-like aspects of the hierarchical filesystem, a central Unix feature that today you apparently take for granted.
...Requiring arcane naming schemes for numbering is the "right way"? Co-opting a folder to be a database is the "right way"? Treating your unsorted filesystem as a sorted list is the "right way"? My intent was to only make light of runlevels' inelegant implementation (and touch on their near-obsolescence, as well), but you've done more than that...
In fact, I can keep a network operating reliably... and much easier without systemd making it more vulnerable because it is developed by morons. I would like to say amateurs, but these are professional incompetents.
Flames aside, I doubt very much that you can keep every network everywhere running reliably. That's partly the point of systemd: to put more adaptability into the service configuration, and let the daemon, rather than the user, determine the correct order for the system services to start.
As a concrete example, I've worked on an embedded system that had to determine its own place in a self-arranging network, set its IP address appropriately, then start system services to manage that network, including determining its own place. The project had a circular dependency that was vital to functionality. The original init scripts to handle that were a mess of conditions, delays, and retries, until the whole thing was scrapped for a single custom-written startup daemon that would undermine and override the whole sysvinit anyway. Systemd could very well have handled the thing, because it has more support for handling service dependencies than just "this one starts before that one".
Everything systemd does crosses a line, because it does everything wrong.
I'm going to need a bit more proof than your authoritative claim, though. Besides being different, what's so wrong with it?
Slashdot Mirror
Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.
That's a very interesting analogy, since I'm currently in a Japanese hotel overlooking a construction site.
Rather than the typical cinder blocks, the bottom two floors are being built from large reinforced concrete slabs, about 1 meter by 3 meters, which interlock and periodically have apparently-plastic pieces. It definitely has increased the speed of construction over laying cinder blocks, and I suspect the slabs and plastic provide some means of safety in an earthquake.
Elsewhere on the technological spectrum, several years ago I volunteered in Africa, where buildings were built with more traditional cinder blocks. The blocks, though, were formed with poor-quality cement, and crumbled when put under load. In America in the 1980s, I was involved in a remodeling project that had to replace some 50-year-old blocks because they were falling apart. Modern blocks (30 years ago) have much more consistent quality, because manufacturers can now chemically test the quality of cement before using it.
In short, construction techniques and technology have indeed improved in the last century. Not even the traditional block dimensions are "fine" for all cases, as I see across the street, though in other areas compatibility is necessary. The requirements have changed, but you seem blissfully unaware. Fortunately, your ignorance of technological progress does not negate its existence.
You're reading far too much into one word. You should try reading the rest of that paragraph.
The first init systems were damned little more than just a shell. After that, we moved to running a single script at startup, and eventually went to runlevels with some common conventions. That's where development stagnated for a decade or two, and that's where I'm drawing my "antique" line. At the time, systems couldn't handle multitasking very well (mostly in terms of race conditions and programmers' sanity), and the massive university systems didn't really need to boot quickly, either, so there wasn't much development in parallel initialization.
Since then, Linux has been created and moved to the desktop, and we have a whole slew of new init systems, most of which natively support modern perceptions of parallelism, security, configuration, hardware, and other new developments since their predecessors moved out of the design phase. It isn't so much that "old is bad" as that the new is more likely to have been designed with modern paradigms in mind. Despite your dismissal, parallelism in particular is important, especially as Linux has taken a role as the embedded OS of choice for smart devices and cheap laptops.
While "change for the sake of change" may be wasted effort, it must be compared against the effort of keeping the old system. For example, how much effort is required of a distro maintainer to write and maintain init scripts for all their packages, including functionality for checking that dependencies started correctly and that scripts follow current best practices? How much effort is required to even make sure that the scripts are numbered in order to start correctly? In an age where building a dependency tree is only a few milliseconds of work, I would say it is wasted effort to make a sysadmin figure it out.
On the side of systemd proponents, I don't think the argument has ever been that "old means bad". Rather, the argument has been that we've learned a few lessons over the past thirty years, and we ought to put those lessons into our software.
So let me get this straight... in order to say "Foo depends on some kind of bar, which happens to be baz on this system", I need to write a "bar" definition that actually runs "baz", and go modify a completely separate dependency file to add "foo".
...and you're suggesting this is clean?
It sounds like you should be looking into your high-availability architecture, not your init system.
With all due respect, that comparison is awful.
In the effort to make an "apples to apples" comparison, it uses only the bare minimum of functionality from each toolset. There's no illustration of dependencies or capability control. It is useful for getting a rough idea of how the init systems' config files look, but not really as the basis for any kind of comparison, especially with regard to advanced features.
Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.
A fair point.
The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place.
Typically sysvinit or mostly-compatible equvalents. From my perspective, they don't want to learn something new, and they don't see the existing system as broken.
And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case?
The obligatory XKCD applies. Most boot processes are fast enough now that it's not really worthwhile for an end user to shave a few seconds off the time. On the other hand, doing something as a hobbyist is entirely about wasting time, so I won't hold that against you.
The biggest improvement over antique boot systems is going to parallel boot chains. Rather than running scripts one at a time, in order, a tree is built to determine what services are dependent on what other services. For example, it doesn't make sense to start the SSH server until the network is live. There are several init systems that do this, differing mostly in how they define dependencies. Some rely on specific services ("openssh-server relies on network") while others work on more generic capabilities ("remote-shell relies on network, and openssh-server is what we'll use for remote-shell").
After parallelism, it gets tricky and subtle. Maybe we don't need all of a service to start before its dependencies. For example, we don't necessarily need all of our DHCP leases assigned before we know which network interfaces are connected. That requires a more granular service definition, but provides a lot more power, especially for systems with very complicated startup procedures. With that power, we can shave a few more seconds off the boot time, because we aren't required to wait while services settle, improving our overall parallelism. That's useful for me (professionally, I build systems that boot with a strict time limit, and may reboot every few hours), but most folks don't really benefit with the added complexity.
Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.
I don't know much about Android init, but I think it uses its own system unrelated to systemd, sysvinit, or any of the alternatives listed in TFS.
Since my day job involves comprehending and troubleshooting init scripts, I'm going to assume that's sarcasm.
There are some good non-systemd boot processes, with nice clean service definitions... there have to be... please tell me there are...
I'm not sure if that's a serious question or an attempt to troll, but regardless...
Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?
In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.
That's always been the standard method in this country. We've had the Boston Tea Party, anti-slavery protests, Black Panthers, Vietnam, Rodney King... and now we yell about pipelines and drilling, elections, foreign policy, and who can use what restrooms.
That said, there is still room for facts and consideration by those who are actually doing the work, and that's encouraging. I've been involved with a number of activist programs hosted by those "elites" who know what they're talking about. It's provided me a very interesting perspective on how complex the typical analysis really is.
Fortunately, the loud voices don't seem to have much effect on the people who are actually affect policy... Unfortunately, the loud protests do distract from those folks, creating the appearance that nothing is being done, leading to further dissatisfaction. There has always been, and will always be, a certain fascination with the folks who complain loudly and reduce complex situations to a simple cause. There are roughly 7 billion people on this planet, and that's about 500,000,000,000,000,000,000 relationships. "Simple" is not a word that applies easily.
Sort of...
It's also very disappointing that the polls and predictions were so wildly incorrect. That is highly irregular, though not indicative of foul play.
I'm not ambitious enough to find the article, but Nate Silver had an informative retrospective piece about how some of the most influential voting blocks ended up voting contrary to what they were assumed to do, while polls concentrated on getting accurate results in other areas more typically "on the fence".
Trump's campaign did a surprisingly good job of swaying typically-blue voters to his side, while Clinton's campaign focused on the traditional swing states. Ultimately, those states that Clinton won couldn't compensate for the masses that Trump won, so Trump won the election. Since the polls focused on those swing states as well, Clinton showed a lead there.
In the future, we'll need to have an analysis of the polls that considers their assumptions about who's important to poll. The reality is that every vote counts, even when you might not expect it to.
Having read earlier reports of this analysis, I'm going to have to respectfully disagree.
From what I read, there was no attempt to find other explanations, like a demographic preference for e-voting over paper, or the local economic costs of maintaining one particular voting mechanism.
Nope, let's just just straight to assuming hacking.
Having worked in theater for a while, I can assure you that ticket sales (in a traditional venue, at least) have practically nothing to do with the house costs... but it's complicated.
First, the house charges rent. That typically covers the wear & tear, upkeep, and basic services for the show during its run. There may be basic crew costs included, or they may be negotiated separately, but the bottom line is a big up-front cost for the producers to put a show on stage at all.
As tickets go on sale, they are priced according to what the market will bear, through a joint agreement between the producers and the house. Front-row seats for a Broadway show pull in above-average prices, but the nosebleed section behind a pillar next to the air conditioner barely sells for enough to cover the processing cost. However, selling cheap seats allows the producers to boast about the number of tickets sold, and helps the house meet goals for community access (which is very important for nonprofit houses). A cut of the ticket sales goes to the house (justified as covering the box office processing costs), but the majority of it goes to the producers... After all, the producers are also paying a lot of the expense to promote the show, often through separate advertising deals with the house company.
To address the original point: Ticket sales are based on the market, not the expenses. A nonprofit house working toward promoting the arts might indeed sell tickets at a huge loss to please their patron donors. A promoter trying to increase a band's popularity might cut prices, expecting to lose money on the whole show in an effort to boost popularity for higher return later. On the other hand, a top-bill show with great reviews in other venues could be priced at a huge profit, and still expect to sell.
Finally, once the show opens, the producers have the captive audience in the seats, excited about the show, and that's when the real money-making starts. Concessions are usually handled mostly by the house, but merchandise is usually purely profit for the producers. That's why the adage about merchandise rings true. It does allow promoters to cut ticket prices and still make a profit on the show, or at least reduce the expense they paid for promoting the brand. For small bands who have to pay their own expenses, this is the best chance they get at turning a profit on the show.
While the OP did indeed ask for practical propulsion applications, the implications of a change in physics theory is enormous, as his example illustrates quite well.
Spectral lines led to the realization that energy is not continuous, but discrete in very small units which can interact with matter, and by inverting that principle, small changes to matter can result in large changes to energy. That directly led to the theory behind semiconductors, enabling transistors and other solid-state electronics, ultimately leading to the entirety of modern electronics technology.
Similarly, verifying a repeatable violation of the laws of physics means that those laws are inaccurate. By refining the theory to fit the new observations, we can also revisit our assumptions about what is possible using electromechanics. To address OP's question, energy, not fuel, becomes the limiting factor in propulsion. That in turn alters the theory of rocketry, which affects the limits of human expansion, providing new areas of study for anthropology and sociology.
However, the scope of affect also lies beyond rocketry. If EM can produce thrust, we may be able to miniaturize the device to a nanotechnology scale, as a new tool for nanomachines. As one example off the top of my head, we may be able to produce self-controlled materials that change shape by rearranging microscopic structures, similar to how animal muscles work by moving actin and myosin molecules.
In short, the actual application of any discovery is the increase in understanding of how the universe works, and from that we can derive advances in technologies.
"Wrong" and "illegal" are two different things. Despite what certain politicians may say, the American judicial system is built to ensure that only people who do illegal things go to jail. I'm not saying it works perfectly at making sure people who don't do illegal things stay out of jail, but that's another discussion. What's important in this case is that we don't just decide "this person ought to be in jail", and invent retroactive mechanisms to imprison them.
First it starts with having an understanding of what's going on. Then it continues with realizing that an assumption isn't necessarily true, and finishes with finding a means to force that assumption to be invalid.
One of my favorite exploits is a privilege-escalation issue on very old Linux systems. In short, you run a program that crashes and drops raw memory into cron's job folder, and when cron looks at the dump, it sees something that looks like a job spec, so cron happily runs whatever was in that memory dump, as root.
This exploit existed because Linux would assume that dropping a file would always be a safe thing to do, while cron assumed that only root would be able to drop files in its job folder. Together, they made a vulnerability.
There's a very good chance that I'm remembering it incorrectly as 3G, when really it's supposed to be 2G. It's been a very long time since it affected me enough to care.
I feel like there's something more to this story.
T-Mobile's "unlimited" plans are what I use, and they've always been pretty straightforward about what that means... They don't hit you with a hard-stop limit, but after a particular chunk of full-speed data, they cut you back to "3G speed". All of their marketing material that's I've paid attention to has stated that plainly (to an engineer), in print that wasn't particularly small.
I can't say I've ever found the advertisements to be particularly misleading (or the policy to be particularly limiting), but I'm not as touchy as some consumers are, I guess.
isn't that what HFT is all about?
No. HFT is legitimate buying and selling, just done at high speed. An order goes through, ownership is transferred... everything you'd expect from a legitimate business, just executed very quickly. What's different here is that this guy allegedly posted transaction orders just long enough to affect market prices, then canceling them, capitalizing on the price fluctuations with separate legitimate trades.
Cancelling orders is a protection mechanism for accidentally making stupid orders, like putting an extra digit in the price. When exploited to significantly alter the market, it's a bad-faith contract, which is generally illegal in most countries, though the particular codified law varies wildly.
So in other words, both acts are unimpressive and require no technical skill, but also both are illegal.
It's always Russia, because we still haven't definitively settled the dick-measuring contest left over from World War II. It's hard to measure while the two main contestants (and new challenger China) keep simultaneously participating in pissing contests and counting notches after fucking other countries.
The metaphor's getting a bit strained, but the bottom line is that it's a mess that hasn't been resolved in the last century. America was doing great in the 20's, horribly in the 30's, then somewhat stabilized after WWII. Meanwhile, Russia was doing decently in the 20s, badly oppressed in the 30s, then pretty unstable (but pretending otherwise) after WWII until the Soviet Union collapsed in 1991. After that, there have been several factions fighting for power, and one of the more aggressive factions has taken control, now looking to solidify Russia as the main superpower of the world.
Then, of course, there are all of Russia's allies that have caches of Soviet weapons, and the ongoing corruption that allows them to get more. Even if "hurt America" weren't Russia's intent, there's enough belligerence in Russia's government that most conflicts can be traced back to some Russian office.
On the American side, we've done little to discourage such saber-rattling. In a burst of benevolence, we've helped overthrow oppressive government regimes, only to be pulled back by our own isolationist factions, leaving a power vacuum that attracts more oppressive dictators. We also tend to be vindictive, highlighting the Russian connections when a bad guy gets a delivery of shiny new weapons.
It's all very complicated, and has several symptoms of an ongoing cold war. Russia makes a public affair about our insecure elections, we make a public affair about their corrupt government. We build new weapons that could threaten Russia, they steal designs and threaten us. It's a stupid dance, and this is just another turn.
But it is being used to collect data on domestic targets which puts it in breach regardless of how many foreigners it's used on/for.
Actually, the case in question was apparently a group of foreign individuals who would always identify their messages with a particular signature phrase, described as "highly unique" to the group in question.
Yahoo was directed to capture only messages that matched that signature, and turn those over to the government, resulting in a high probability that only the foreign targets' messages would be collected by the investigators. That high probability, even if imperfect, is good enough to pass any legal or ethics review, because the investigation is actively trying to comply fully with the law.
The letter and spirit of the law also says that the courts are solely responsible for its interpretation.
An interesting choice of comparisons.
After writing the famous "Go to statement considered harmful" essay, Dijkstra himself soon recanted, and clarified that there are particular circumstances where GO TO is the most straightforward solution, and results in the most readable and maintainable code. Of course, by then it had already developed such a stigma that there are now languages lacking such a construct, and those particular circumstances are now written with uglier and more confusing code.
It appears BUG_ON() is similar... There is a correct way to use it, that results in useful testing, perhaps better than any other method. Removing it completely may very well be a case where the cure is worse than the disease.
A specialist MD develops an instinct...
...or so you hope. Unfortunately, I've worked with enough doctors who just don't care that I won't accept that as a blanket statement for the entire profession.
...all I'm proposing is an extension of the increasingly popular concept to any informed patient.
But now you have to define what an "informed patient" is. I've also worked with enough patients who spent too much time with WebMD to accept that people can be well-informed just by reading a few articles on what they think applies to them.
...products labeled "FDA Approved" will be worth, on the average, more...
As long as that label is honest and respected, sure... but there's nothing to stop a fly-by-night operation from selling a drug with a not-quite-approval label and unscrupulously allowing doctors and patients to interpret the labeling (and marketing) as though it were actually approved. That, in turn, dilutes the FDA approval process, because if you can sell your drug enough to become standard without the hassle of approval, why bother? Do you actively check for a UL label on all of your electronics?
I hate to appeal to emotion, but the consequence here is literally peoples' lives. If it costs more to go through the FDA testing process, but saves the lives of people who would have been misinformed, is it worth the price? Conversely, do people deserve to die because they misunderstood the risks?
init starts and stops processes to attain different run levels. That's it. Period, the end. One small tool, which does one thing correctly.
I'm a bit more familiar with the program than my sarcastic post let on. Originally, init's job was to be the first process, period. It'd launch a shell, which quickly became "launch a login prompt" and then changed to "launch a bunch of services" and finally "launch everything the user wants to run for this runlevel". In short, to answer the original request, running getty is just about all you need.
There is nothing whatsoever magical about getty. It is extremely straightforward. It is one small tool, which does one thing correctly.
Relax; it's literary exaggeration. Once upon a time, as I recall, getty would manage its own tty connections. Now it takes a parameter so you can tell it to connect to a given device. If you want init to support multiple ttys right from the start, you'll want that feature.
There is no reason to use anything more (or less!) than a script for configuring networking. Scripting is a central feature of Unix.
Anything you can do in a script can be done manually. Isn't that the whole point of having non-compiled scripts in the first place?
My Debian system has 57 init scripts. If that kind of complexity scares you, perhaps computers are not for you.
Mine has 96, averaging 120 lines per script. I never said it scares me. I'm merely making fun of the aversion to Systemd's complexity, by highlighting the fact that you already have such complexity, but it's pushed out and duplicated (usually poorly) in your init scripts.
Yep. Using central Unix features like linking is the right way to do this. It utilizes the database-like aspects of the hierarchical filesystem, a central Unix feature that today you apparently take for granted.
...Requiring arcane naming schemes for numbering is the "right way"? Co-opting a folder to be a database is the "right way"? Treating your unsorted filesystem as a sorted list is the "right way"? My intent was to only make light of runlevels' inelegant implementation (and touch on their near-obsolescence, as well), but you've done more than that...
In fact, I can keep a network operating reliably... and much easier without systemd making it more vulnerable because it is developed by morons. I would like to say amateurs, but these are professional incompetents.
Flames aside, I doubt very much that you can keep every network everywhere running reliably. That's partly the point of systemd: to put more adaptability into the service configuration, and let the daemon, rather than the user, determine the correct order for the system services to start.
As a concrete example, I've worked on an embedded system that had to determine its own place in a self-arranging network, set its IP address appropriately, then start system services to manage that network, including determining its own place. The project had a circular dependency that was vital to functionality. The original init scripts to handle that were a mess of conditions, delays, and retries, until the whole thing was scrapped for a single custom-written startup daemon that would undermine and override the whole sysvinit anyway. Systemd could very well have handled the thing, because it has more support for handling service dependencies than just "this one starts before that one".
Everything systemd does crosses a line, because it does everything wrong.
I'm going to need a bit more proof than your authoritative claim, though. Besides being different, what's so wrong with it?