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.
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.
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?
I would hope to hell that my doctors have an understanding of what's actually happening! That's what med school and years of experience are for.
I have some very bad news for you, then...
Since this is Slashdot, a car analogy may be best. If you take your precious high-performance sports car to a mechanic to find out why it's not getting the power that it should, he can look at the engine, perform tests and measurements, and tell you that your engine needs a fuel with a higher octane rating. He may not know precisely what an octane rating means chemically, or what chemical processes are taking place during combustion that affect the engine's performance, but he knows the cause of and solution for the symptoms presented.
Similarly, a physician does not usually need to know all of the biological processes that a particular drug affects. Knowledge of common interactions and side effects is necessary, but not the rare effects or anything easily treatable. Basically, if the treatment isn't going to be worse than the disease, they don't need to waste their time or memory thinking about the minimal chance of a mild adverse reaction.
This is not to disparage the medical professionals in any way, but only to clarify what the scope of their job requires. A programmer doesn't need to understand the particle physics that make semiconductors work, a carpenter doesn't need to know how to grow the wood he uses, and a doctor doesn't need to know every side effect for the 10,000 FDA-approved drugs he can prescribe today. Such knowledge just isn't necessary to be an expert in the field.
Making FDA decisions advisory, rather than mandatory would preserve its essential testing function...
...but completely undermine the incentive to actually perform that testing thoroughly and ethically. After an effective marketing campaign, there's no difference between "submitted for FDA approval" and "approved by the FDA", even if the former really means the manufacturer submitted only a brief description of the drug and it was rejected immediately. If, even without approval, the drug can still be marketed and promoted and prescribed, then it's more cost-effective for the manufacturer to run damage-control PR spin after a bad reaction than to actually ensure their products are safe in the first place.
And on the FDA site, I see databases of approvals and lists of rejections, but no details on rejections. We should have as much detail on rejections as we have for approvals. The reason we're not seeing that information is that...
...such information is rapidly out of date, and doesn't matter because doctors can't prescribe those drugs, anyway. The only purpose it serves is to terrorize the public with bad news about a drug that might eventually be considered safe, which in turn just makes it more difficult to convince patients that they should follow their prescribed treatment.
If you want to follow what's going on, I'd recommend some industry publications, which usually strike a nice balance between the technical details and the ultimate impact.
I'm not too terribly familiar with init's requirements, but isn't a "working and viable init.c" basically something like execl("/sbin/getty", "tty0");? It runs, it provides a login shell to the user... what more do you want?
Oh, you want preconfigured settings? Real Linux Users set that stuff by hand when they log in, but fine. We'll add that to the init daemon.
Multiple terminals, too? Fine, a bit of magic with getty, and you're good.
Oh, you want it to start vital services like networking? You could do that with ifconfig, but whatever... Sure, let's give it some network support.
Wait, and now you want to be able to configure all that without compiling? This is getting absurd, but if you insist, we can make a hundred little hundred-line shell scripts, and just run them.
...in different ways? You're really going to ask to run your shiny new server with completely different sets of services at different times, and you're just so spoiled that you can just reconfigure it as needed? Why the hell did we make the damned thing so configurable anyway, if you're not going to use it? Fine... Since you're asking so nicely, we'll throw in a bunch of folders... just link the scripts you want, and names the links so everything's in the right order.
Another request? What do you want from me now? You can't even keep a network operating reliably, and you want your init daemon to do the work for you? Alright, but this is the last straw. Now your configuration scripts can run in parallel, have dependencies, and they will run other scripts to see if they can run your services yet.
One of these steps apparently crosses a line, though, and causes enough discomfort that folks derail discussions.
Perhaps I should clarify that statement by saying that the reports are available, but I don't care enough about this particular case to go find this particular report, just to satisfy what I see as a mob that complains about things they don't bother to understand.
So in short, because someone asked why an incentive program isn't useful, you want a witch-hunt to kill off anything you don't like, without any consideration for context.
It just seems so obvious that running a bulldozer through an in-place operational government is the best way to improve efficiency and integrity.
The FDA does give a full report with their rejections, but I don't have a copy of this particular one readily available. My best source is that I used to work in the pharmaceutical industry, in the process for getting new drugs to market. In short, it's a mess even without any accusations of corruption.
I don't think I've ever heard of a modern drug getting approved on its first try (though that's also not where my experience focused). The most common reasons for retesting were things like imprecise side effect rates (two patients in the trial had a headache, so the whole trial needs to be 10x larger to reduce the margin of error) or a lack of documentation (you computed this incidence rate using the standard formula, but exactly what is that formula?).
The problem with a user-centric approach is that you start having public health decisions being made by people with no understanding of what's actually happening. Physicians usually focus on diagnosis and treatment monitoring, not understanding the biochemical interactions of the drugs they recommend. Pharmacists understand the chemistry and interactions, but patient risk analysis and diagnosis is outside of their job. Add a layer of traditional American marketing on top of that, and you have a perfect market for snake-oil salesmen to promote insufficiently-tested medicines to doctors and patients who have no way of knowing how unsafe the medicine is. Doctors can be conned, too.
If you're not careful, you're going to catch something.