Only $340 to have a qualified technician disassemble a large electronic device, connect specialized repair equipment, and perform the repair, then reassemble the device again to meet original specifications, perform a functionality test, and recertify the device?
$30/hour for 10 hours (plus about 10% overhead) sounds pretty cheap, actually... or would you prefer that the cost of such repairs just already be worked into the cost of the initial product, which was sold several years ago and was perfectly suitable for its purpose during that time?
The big lie about modern electronics is that they're easily repairable.
Yes, the TV in question can be repaired. Mr. Cauthon can disassemble the thing, remove the boards, desolder the flash memory, attach it to a reader/programmer, change bits to match a known-good unit, then rebuild the entire thing to see if it works. It's not going to be easy, but it will work... Of course doing it that way would cost a lot more than just replacing the board with a spare and resetting the memory, so that's what the service center will actually do.
Of course, all of that work really should be done in an ESD-safe environment, with clean air and properly-trained technicians. While a random software engineer might have the tools and ability to do the work, it's very unlikely that the repair quality could be good enough for LG to accept any remaining warranty (explicit or implicit) on the unit, which they may be legally obligated to do if they provide assistance.
It's easy to forget just how fragile electronics actually are. We are used to consumer goods, which have been designed specifically to handle the stress of normal use, but after the initial manufacturing, it's just not cost-effective to do troubleshooting and repair work with such delicacy. It's much easier to just replace what's replaceable with newly-manufactured parts, fresh from the mechanized assemblers that can handle such precision.
...just like guns "can be exploited" to shoot people, and vehicles "can be exploited" to run over them.
It's a very dangerous argument you're making, that liability is derived from the end condition, rather than the initial effort. As long as LG put forth a reasonable effort to ensure that their products are free from defects, which seems likely considering the product timeline, LG is very unlikely to be at fault here.
I'll also note a bit from TFA:
It is unclear at this moment if Cauthon's relative downloaded an app from the official Play Store, or from a third-party source.
The reason there were jumps before as the die size decreased was that the semiconductors took less time to change states, so they could switch faster. Now, though, the parts are getting close enough together that quantum tunneling becomes a major problem, and increases in switching speed are accompanies by a drastic increase in error rates. We can still make the features smaller, but increases in speed will likely be counteracted by increases in required stabilization time.
Rather, the biggest areas for future work are in parallelism and prediction. At the cost of complexity and chip area, we will see more predictive computations, optimizing the slowest operations into little more than lookup tables. We can also expect to see more bus channels added to chips, which in turn will give far greater I/O capability. Similarly, expect to see more features built into chips, moving toward desktops being essentially a SoC with a breakout board.
In short, we've reached the point where raw clock rate increases are extremely difficult for only marginal gains. Increases in speed, however, are sill promising, but they come from making better use of the cycles we have.
There is simply no way to... enforce contractual terms after money has changed hands.
Well, fortunately that opinion was obsolete about 5000 years ago, when debt contracts became legally enforceable. Because we can legally oblige someone to follow terms after an exchange of money, we as a society developed investment, credit, loans, and complex economics. Effectively, if all exchange was limited to what was available at the time of the transaction, we'd be trapped in a barter economy.
Your rejection of the law and assertion that it cannot possibly be exactly how it's been for millenia does not in any way change the fact that the law exists and has worked very well overall.
While we're at it, let's discuss the other points you've fumbled.
You might as well try and justify child labor...
Which, when legal, is legal and justifiable. It didn't magically become illegal just because decided it was immoral. Rather, it was legal prior to any laws outlawing it, and continued to be legal until there were new laws declaring that children were not legally employable. That had some major side effects, like disruption to family businesses, so the laws were clarified to grant limited exceptions where the child's parents consented on the child's behalf. That led to more problems in cases where the parents did not care about their children's well-being, so the laws were again adjusted to the form we have today, where it is a complex set of rules to determine a minor's eligibility for hire.
Making a blanket law like "all minors are unemployable" is a very short-sighted reaction to the problem, and leaves you with the problem of starving farmers whose kids can't help harvest the crops. Good luck justifying that.
...and indentured servitude
...which is a very interesting application of contract law. At the time, indentured servitude was a simple contract: I give you X, you work for me for Y years. The unfortunate downside to that was that during those years, you couldn't do anything else to support yourself. This led to laws that contracts must not leave either party destitute, such that they would be unable to live reasonably during or after the contract. Once those laws were enacted, indentured servitude quickly gave way to employment contracts, that usually specified the same deal as the servitude, but with livelihood provided during the term of indenture.
Notably, an employment contract is a contract. You agree to certain conditions (working), and the employer agrees to conditions (payment). If you quit the job, the contract might say you have to pay back your wages or meet other demands, and they'd be enforceable, too. The contract could prohibit you from working in the same industry for the remainder of your contract term, and it'd be enforceable.
Since a key aspect of a contract's consideration is that you are giving up certain rights of your own, the contract may supersede other laws. This is now coming into play for EULAs and service agreements, as arbitration clauses are being included in the contract, overriding local laws regarding dispute resolution. The debate in the courts is whether your right to a court-based resolution is waiverable by a contract or not. There have been decisions on both sides, so the matter is not yet settled.
They're no different from those "employee handbooks" that have a little notice at the end saying that the handbook is not an employment contract.
That's correct. They are not contracts, which means that they do not invoke contract law over any other laws that are in place. That's very important, because it means that nothing in the handbook is binding by contract law.
Without the handbook being a contract, the law falls back to whatever would be in force without the handbook's existence. Usually, that's a law saying something to the effect of "the employer wil
Firstly, "click to accept" has been upheld many times, It's been overturned on a few rare occasions, in instances where other circumstances (like local sales laws) invalidated the EULA conditions.
1) In the particular case in this discussion, writing the airline with new terms would immediately be laughed out of court. It's not the normal method of doing business, and the AC proposing the scheme stated that he knows the airline has no process to handle the proposed contract, so the contract is obviously being made in bad faith.
2) In a service contract, if the terms change there is a window (typically 30 days, but it depends on the jurisdiction and applicable, consulmer protection law) during which you can cancel the service or otherwise reject the new terms (though that usually triggers other terms in the contract, like cancellation). However, it's important to note that a previous contract already exists. That changes the legal posture significantly. Again, in the case of sending your own terms to an airline, there's no pre-existing relationship, and your case would be thrown out of court pretty quickly.
It depends on the terms of the EULA, and the implementation, and ultimately what it can convince a judge to decide.
The basis of a contract is that both parties are giving up legal rights in exchange for others. As an example, in a EULA the publisher is giving up certain exclusivity to copying, and you are giving up rights to privacy, warranty, and a chunk of money. Yes, the contract can also include escape clauses that define the actions (like failure to maintain a support contract, or failing to run updates, or clicking the "I don't accept" button) that will terminate the contract, and may entitle you to compensation (like a refund).
The legal complication comes from software that requires exercising the contract rights (copying to RAM) before seeing the EULA. In the case of installers and online services, and the infamous "by breaking this seal" stickers, that's a problem, and that's what some courts have decided against. The only real result is that now, EULAs are written to separate pre-EULA actions from the contract terms, so you can view the EULA before accepting, but still can't really use the software without accepting.
No, the courts did not invalidate contracts en masse. They just closed a loophole in a few specific cases, where the contract terms didn't mesh well with the actual system behavior.
If you write back and they don't do anything to explicitly accept the new terms, they're generally unenforceable. You buying the ticket (or installing software, or using a service) is an action that indicates you accept their contract. Actions can accept contracts. Inaction generally cannot.
"Alternative right" and "conservative" are not really synonymous. The term "alternative right", often shortened to "alt-right", was coined by a white supremacist to distinguish his movement from the more traditional conservative views.
Broadly generalizing, the focus of the typical conservative is economic strength, usually through privatizing services and promoting individual liberty, within the limits of societal conformity. The alt-right emphasizes the conformity to the exclusion of other races and ideologies, with any economic efforts coming secondary, as they are seen as being more easily manageable once white supremacy is established. It is most easily contrasted with the Libertarian label, which typically emphasizes the economic principles while minimizing the social aspects.
No, not everyone who fits the "alt-right" category fits the "neo-Nazi" category, but there is significant overlap, especially (as crypticedge's comment mentions) in the Trump-supporting sections of 4chan. There are some alt-right folks who try to stay away from neo-Nazism, but 4chan's preference for anonymity makes it very difficult to isolate that distinction in the community.
No, it's not about "labeling and demonizing by the Left". The left-leaning folks who are inclined towards demonizing already compared conservatives to Nazis. Rather, the new prevalence of neo-Nazi and alt-right labeling is coming mostly from those who align with the more traditional conservatism, in an effort to separate themselves from the white supremacist (and other) controversies.
The groups that get the neo-Nazi label are the ones promoting Nazi propaganda, ideals, and methods. There are groups actively using the swastika symbol as an identity and using Hitler's writings as a doctrine. They advocate the same racial cleansing the old Nazis did, and the same totalitarian fascism. They get the name neo-Nazis, because they only differ by being more recent.
No, the label is not disrespectful to victims of the Nazis. Rather, what is disrespectful is to immortalize the Nazis by granting them some kind of unique status as the gods of oppression and death. By insisting that nobody today could compare to the Nazis, we further distinguish the Nazis as being something special, more powerful than mere mortal humans. In effect, declaring the Nazis as an untouchable evil would grant them status as a superior race, exactly as they wanted.
That would be disrespectful. That would undermine the victory of World War II. That would be an incredible disservice to each and every victim of the actual Nazis.
I'm not going to do that.
I'm going to continue to declare that any group that tries to act like the Nazis are neo-Nazis. I'm going to continue to treat them as humans; no more and no less. I'm going to continue to do what I can to ensure that the horrors of the Nazis are always presented as a mundane evil that got out of control, and I'm going to continue to teach that every person, everywhere, has that same capacity for evil, regardless of race, ethnicity, gender, sexuality, or economic status. They also have the same capacity for good, and it is the active choice to work toward that good that makes someone worthy of a unique place in history.
Today is the first time my gaming computer has been powered on in about two weeks, and I was able to launch DRM-protected games just fine in offline mode.
I'm not familiar enough with Steam's DRM to address your concerns about a token, but it does appear to work just fine in offline mode while offline.
As I understand TFS, there's a lot of doses available now that could be used to cover an outbreak, but those are not covered by full regulatory approval, and manufacturing capability is also probably rather low right now.
Once full approval comes through, in about a year, the vaccine would be generally available, and I would expect it to become part of the recommended treatment for anyone going to a risky area, as is currently the case with the yellow fever vaccine.
Well, that'd be great... but who's going to fund the synthesis of a plane-load of vaccine, and the training for a plane-load of qualified staff to administer it, and then also fund the two plane flights to Africa? You're asking for a few tens of millions of dollars, minimum... and that's not even considering the logistics involved in ensuring that the vaccines aren't immediately seized upon landing, and used as leverage in a civil war.
Maybe you think that the lab techs, nurses, pilots, maintainers, security personnel and diplomats should all just volunteer their time. That's nice, but then who's going to volunteer to feed them as well? Maybe you think the pharmaceutical company should just pay for everything, but they already do a lot of that, and that's partly why American medicine prices are so high.
...or maybe you just have no idea how the world works, and just want to enrage Slashdot readers.
Steam is different... it's not your perfect ideal, but it's different from the abysmal pit we were headed for before Steam. Steam is a decent compromise between the anti-cheat and anti-piracy efforts of vendors, and the pro-consumer model apparently favored by you and others.
See, what I remember from my history is that those multiplayer games were full of cheaters and hackers, to the point where half of the game was figuring out whether your game was legitimate or not. I remember seeing casual piracy with cloned disks and hundreds of "backups" being passed around my networks. I also remember seeing the start of server-side games that lost functionality when their studio closed and their servers shut down. I remember the predictions that that would be the only effective way to combat piracy, and I remember reverse-engineering efforts claiming to ensure the longevity of games... and I remember their failures, too.
Steam is not perfect, but it is different... It mostly works.
Americans tend to care about "freedom". Not any particular freedom, mind you, but they cling to the fantasy story that they are somehow "free" in an abstract sense, and any limit on that freedom is a grave assault on their very essence. However, the more recent evolution of this philosophy has extended the concern to others' freedoms as well. The privacy advocates don't have anything to hide themselves, but they're sure that someone out there has horrible secrets they're trying to keep from the Big Bad Government. The civil rights advocates aren't being persecuted, but they're supporting those who are being persecuted. The gun lovers don't own bazookas or urban-assault weaponry, but they want to be absolutely sure someone else can get them.
International politics, on the other hand, looks a lot more like the stereotypical spaghetti westerns. Every nation is concerned primarily with their own interests, and everybody's just one sufficient excuse away from attacking someone else. Their cattle came too close to your territory? That must mean they're your cattle now. They cut down a tree you liked to look at? That must mean they owe you reparations. Their drunk belligerent son insulted your father? This calls for a duel to the death.
There are also the outlaws. There are certain countries who have caused more trouble than their existence is worth, and it'd probably be best if they were relieved of their sovereignty, but, they still have a few powerful friends. You can't just kill that guy who annexed your land, because you'd be dead yourself in short order.
Now, the UN is suggesting new rules. Continuing the metaphor, this is effectively the equivalent of the townsfolk coming together and agreeing to not breed coyotes. No, there's no real way to stop someone from breeding coyotes if they want to, but everyone else has said they don't want more coyotes around.
What this means is that there is a new excuse in town. If someone accuses you of coyote-breeding, they might use that as justification to steal your horse. If they can prove you're breeding coyotes, they might be able to get a posse to kick you off of your land and take it for their own. Your friends won't have much ability to protect you, because they don't want to be associated with a low-down dirty rotten coyote-breeder. With your allies gone and a bounty on your head, everyone with an opportunity will try to prove their commitment to the law by coming after you.
Of course, it's very difficult to claim that breeding coyotes is bad when one is already doing it themselves. This is exactly what happened with nuclear weapons. The United States had them, so we couldn't effectively ask everyone else to ban them. Right now, though, there's very little interest in fully-automatic lethal robots. Even drone strikes are commanded by a human, and there is significant political pressure to keep them that way. The closest we have to automated killing machines is the common land mine, whose use is finally banned or regulated by most countries. There are also IEDs, whose use is being publicized as an indiscriminate assault on civilians... and in response, the good guys of the world continue to hunt those dastardly villains to protect the innocent!
In the public perception, there is a huge difference between the freedom of people and the freedom of nations. Yes, a country bound by the UN rules could still create AI killers, but there are effective human-led counterattacks to them. There is no benefit to pursuing the prohibited weaponry.
So when you decide to mitigate the risk by bringing it all in-house, you can't.
There are reasons to bring infrastructure in-house, but risk mitigation isn't one of them. Your risk is mitigated by having an SLA with a provider whose primary function is to maintain those servers, with penalties attached for downtime to compensate for the loss.
For large projects at large firms such as those mentioned in the article (Walmart, Ford, etc), you need these types of people on hand anyway. Farming out shit "for convenience" isn't an excuse for being lazy.
No, those companies really don't need a devops sysadmin on hand. They need sysadmins in other areas, who can focus on those areas, but they don't need nearly so many supporting the development.
Sure it might cost more, but if you farm it all out your business will consist of workers who are jack-of-all-trades and master-of-none.
Really, it works the other way. If you farm out distinct areas of your infrastructure, the experts you have don't need to work in those areas, and they can specialize in the areas in which you do need in-house support.
A company I have worked at has reasons (some of them even decent) to have everything in-house, and as a result of that, my sysadmin team was highly fragmented. We had a dozen members, but were expected to support a dozen different efforts, so we had these guys who knew X well, those guys who knew Y well, this one guy who was a Linux expert, that guy who was a Windows expert... and as a result, we were effectively all on-call 24/7 because we were spread too thin. If any system broke, we had to first figure out who the expert was, and then contact them directly.
Most software managers don't care too much if someone that can produce a NSL gets to see their source code. They are concerned about direct competitors having access, and they're concerned about having to pay sysadmins to handle the development environment. Sysadmin labor isn't cheap, and neither are the servers, storage, backups, auditing, or workflow tools that make development happen.
If your business is making software, you can just pay GitHub for that infrastructure, and focus on your software.
Have you not considered the possibility that the developer wanted different runtime guarantees than the standard library sort provided?
Yes, I have, and find it extremely unlikely that the programmer had any idea what he was doing. Mostly that analysis comes from the knowledge that the particular software package was an interface for a low-speed IO device, and could have probably have performed just fine if it relied on a bubble sort. Then again, I've also worked with the programmer responsible for that particular package, and it wouldn't surprise me to find that he had actually written his own bubble sort...
There are very good reasons to use something other than the bog standard quicksort with a heap sort fallback (aka introsort) in a lot of scenarios, be they server services or even games.
That's not really disputed, but there are third-party libraries that provide many sorting options, without having to write (and debug, and maintain) it yourself. If you have a very good reason to use a particular algorithm, find a library that provides it.
For either games or server services, that standard library introsort would never be used if I was head of the development team. No chance in hell does it perform better than radix sort (for game scenarios) or has the best possible worst case runtime (for server services.) Its a complete no-no to use it.
It sounds like you don't really know much about data processing scenarios. I once had a mentor who said something to the effect of "If you're thinking about your sorting, you're doing something wrong". The reality is that except for the most demanding applications (like rendering on the GPU), the programmer shouldn't need to think about what sorting algorithm is being used. Rather, the programmer's primary concern should be writing clean and maintainable software, and leave the exact implementation to someone else, who only needs to write according to an API specification. If that spec includes performance targets, then it will require particular algorithms. Otherwise, anything reasonably efficient will do the job, and it becomes a point of testing to compare different libraries for required functionality.
For example, let's consider the high-speed sorting used to render a 3D game world. The game programmer just needs to build the world in the game engine, and the engine will handle the sorting. The engine programmer only needs to worry about getting the data from the game library to the renderer, and the renderer will handle the sorting. The render engine programmer finally has to think about sorting algorithms... but his choices are driven primarily by the data structures present and the hardware optimization available, which may drastically change the run times of algorithms. With the appropriate hardware available, the render engine may pass off sorting to the GPU, using some of the SIMD processing capability to (for example) run a Batcher sort, rather than a radix sort on the CPU. I am told that's actually what nVidia's "game-ready" drivers do: They forcibly replace a game's poorly-optimized code with equivalents that use nVidia's hardware more effectively.
On the server side, I will refer to another aphorism: "Premature optimization is the root of all evil". If using a custom sorting method means moving data around outside of your database, you're not going to get a performance improvement. If you're concerned about worst-case performance because you might see it in real use, you should be thinking about security, not performance. If you're optimizing the application to improve user load performance, it's usually cheaper to just buy more hardware and run more back-end servers. In short, sorting is rarely the most effective target for optimization, so it's generally not worth the cost to improve, when efforts could be focused elsewhere.
> That's one of my criticisms of FOSS developers, they can be a bit crazy with their dependencies.
You know that because you can see them.
My day job involves creating itemized lists of dependencies for a very large project. I can assure you that both open- and closed-source software is horrible, though I do have to admit that open-source tends to be a bit worse on the unexpected-dependency front, for a few reasons.
In closed software, there is a lot of effort spent recreating common elements. I cringed when I found a file named "sort.dll", but it's probably exactly what it looks like: A developer didn't want to depend on outside code, so they wrote a sorting function as a library. Without an audit like mine, nobody would ever notice the silly practice of rewriting what's probably built into their language, and readily available in other third-party libraries.
Open-source software, then, is more transparent. If a FOSS project reimplements a sort, it will eventually be discovered and mocked until it uses the third-party library. This is fine, as it also reduces the complexity and size of the FOSS project. However, it does then lead to a bit of shock to see that the "widget" package depends on 53 other packages including "libfoo", "libbar-dev", "libbaz-ng-perl-1.03-sparc", and so on. Compounding that, it's also trivial for the FOSS project to actually use that library, because the library itself is likely FOSS, with a compatible license. Even if all your project needs is a single function, there's no cost to depend on an entire library... and a different one for a different small part, and so on.
The tendency to include a long list of dependencies makes my job worse for FOSS, because I can't just shrug my shoulders and give up after listing the one software package without any named dependencies. On the whole, however, it does ultimately lead to a smaller (and more traceable, and higher-quality) codebase for a final system, which is why the hardware requirements for a FOSS system tend to be much lower than an equivalent system based on closed-source packages.
Despite penalties, there are still those who spoof the traffic light priority systems used by emergency vehicles. There will be those who abuse this too. In general, this would be merely an annoyance.
I like that example, too. A commuter could claim to be an emergency vehicle, and expect other cars to move out of the way. Of course, that commuter would then be disappointed when the automatic systems ignore him because he lacks flashing lights, a siren, or a proper crypto certificate identifying him as an authorized emergency vehicle.
Existing systems widely use infrared beacons, which are easily spoofed. Newer systems actually have authentication between the vehicles (with onboard GPS tracking) and a central control server, and the server changes the lights as the authenticated vehicles approach. As technology and cryptography have improved, security has improved as well.
But what if this is used to control or effectively stop your vehicle? How long before police used it to stop vehicles?.
Probably never, because again the V2V system is designed to be advisory. If such a capability is built in, it is trivial to add authentication, such that (for example) only police who have received an authorization within the last hour to stop your car specifically will be allowed to stop your vehicle.
Or someone that wants to stop a woman on a deserted road.?
They'd need to be in a police car, with a valid standards-compliant certificate from a local jurisdiction authorizing them to access the car-stopping function, or their polite request would be rejected. To me, it sounds safer than just letting anybody with a light bar and a CB radio pull someone over.
The ne'er do wells could wreak havoc using this system.
Again, the ne'er-do-wells can already wreak havoc using existing systems. V2V only adds the possibility for authentication and information where there is no such capability today.
Exactly... this is the part that worries me... they talk about 128 bit encryption and all that jazz, but this isn't a negotiated connection people...
Eh, sort of... There are parts that are broadcasts, and parts that are connections. It gets complicated.
it's transmitting your telemetry in the blind, hoping that others will act on it.
Wait, no, stop. Let's clear this up right now: The transmitter doesn't care what you do with the information. It has absolutely no benefit solely from transmitting, which is why the government is stepping in to say "transmit, dammit!" Unfortunately, that invisible hand of the free market works against us here.
Rather, the V2V transmission is advisory, providing other vehicles the option to act on the provided information. That is one more option than we have now with non-transmitting vehicles, but like any other option, it will be validated and weighed against the other navigation options.
As such, everyone will be using the same encryption key, which will make it trivial for someone to transmit false information.
Not really. I'm not terribly familiar with the crypto for V2V, but it's pretty trivial to make a suitable encryption system. We need nonrepudiation (showing that a particular transmitter said a particular thing), authentication (showing that a particular message comes from a trusted source), and integrity checking (showing that a message was not altered). As noted by another commenter, PKI can provide all of those things. Essentially, each vehicle broadcasts beacons with its own decryption key, which is different from the encryption key it uses (and keeps secret). Telemetry messages are then sent with a plaintext vehicle identifier and an encrypted payload, and receivers just need to remember which decryption key belongs to which vehicle.
There are literally dozens of ways I can think to abuse this capability for fun and profit.
...and there are dozens of ways to counter them. It's easy to play armchair engineer and think of ways to abuse the system, but it's equally easy to find effective mitigations. In the decade or so that I've been following V2V technology, here are the most common ways to deal with attacks:
Firstly, since V2V is advisory, anything that doesn't make sense can be ignored. No, nefarious hackers won't be able to coerce your car into running through a crowd of schoolchildren. You'll have to do that yourself.
Second, as noted elsewhere, the system doesn't have to be perfect - only an improvement. At this very moment, there are literally dozens of folks driving slowly in the wrong lane with their blinkers on. That's bad information right there, and our current driving systems cope with it by recognizing the problem and working around it.
As a third foil against the most common complaints, the keys and identifiers don't have to remain attached to your vehicle forever. There have been test implementations that regenerate identifiers at every trip, or randomly while traveling easily (like down a straight highway). With few other cars around, it's even possible for your vehicle to turn off transmissions, and reappear later as an apparently-different vehicle. Effectively, the only way to track someone reliably is the old-fashioned way... physically staying in radio range.
The other issue is this: The expected range these operate at is defined by the size and quality of the antennas they intend to use, but with improved listening capability the range is much further.
Eh, sort of... but radio doesn't quite work that way. As you get further away and get a bigger antenna, the amount of noise (and other transmitters) also rises. Roughly speaking, the amount of noise rises linearly, and the strength of the signal drops off quadratically, according to the inverse-square law.
Even with a huge antenna, you won't be able to follow a single car very
Your colorfully-worded argument has convinced me that you have absolutely no idea what you're talking about.
Essentially, you argument is that the system can be used to tell vehicles false information. However, that's entirely possible today with the existing information systems. You can turn your blinker on without turning. You can randomly apply the brakes and slow down. You can weave through traffic, and disobey lane markings.
No, V2V is not going to replace common sense, or the algorithms in self-driving vehicles. If a car announces a planned path, it's not going to be trusted outright. Rather, it will be corroborated with reports from the receiving vehicle's sensor suite, other vehicles, and even fixed landmarks.
To illustrate, let's consider some example scenarios, where I will play the bad guy, with a significant technical ability, no morality whatsoever, and a strong desire to keep noisy traffic off of my quiet little street. For ease, we'll assume no functioning cryptography, focusing only on algorithmic security.
It would be pretty easy for me to make a little beacon to announce that my road's under construction. However, with no construction cones nearby, no proper roadsigns, and no road crew, vehicles would have little reason to trust my beacon. They might put a little more weight into their road sensors looking for potholes, but that's about the extent of my influence. Of course, I could post some fake construction signs, but that's illegal under current law, and the only difference is that I would be adding a radio announcing to the police that I've put up fake signs.
Let's get a little more malicious. I could spoof two vehicle transmitters, announcing an accident. Surely, traffic will route around it for a while, but eventually something will come down my road anyway, and notice that my transmitters' announced locations don't actually correspond to vehicles. In fact, it sees the road is clear, and announces that observation on the network. That causes another vehicle (which would really prefer my road anyway) to try driving past, and it corroborates the report, announcing that my transmitters are liars. Their spoofed vehicle IDs, then get flagged as fraudulent, and I have police coming to my door.
If I'm going to end up with a visit from the police eventually, I can at least make it interesting, and get the FCC involved. I can just jam all V2V traffic in my area, making my road an unknown compared to the safer routes around me. That may work for a while, but it doesn't deter any traffic that would have normally gone down my road. Without V2V communication, the vehicles fall back to their normal radar and vision sensors.
Now let's suppose I get really angry, and head out on the highway to wreak havoc. I can announce that I'm moving perfectly fine, going straight ahead. I can announce that my brakes are in great condition, that I have a full sensor suite, and all my data is trustworthy. I can announce a few spoofed vehicles just out of sight that trust my data. Everything says it's safe to come close to me, and nothing will go wrong... until I slam on my brakes. Then, the car behind me slams on his brakes automatically, because it rightly knows not to absolutely trust anything coming from V2V, and it's still watching my car with forward sensors. It also announces to the network that we're stopping, so all the cars for a mile behind me brake, too, and the ones that can shift lanes will escape. Even if there is a collision, the damage will be minimized by the slower speed and rapid self-preserving coordination. The flood of messages about the delays will be weighed more heavily than my fake announcement of clear conditions, so the affected lane will be avoided, and vehicles will move away as they're able. I've disrupted a few folks' smooth sailing, but it's not catastrophic.
No, the system isn't perfect, and it's not designed to require perfection. The people actually doing V2V work are well aware of the limitations of network communications, and are designing systems to work around malicious actors. In the worst cases, it's still better than human drivers or isolated automatons, so it's still a net benefit.
1. Triangulation, self-identification, and multiple sensors.
2. Multiple sensors.
There's a common thread here.
Any V2V system is advice-only. My car can advise other cars that I'm in this particular place, and I'll be turning right up ahead. That lets the car to my left know that I will be getting out of its way, and it will have an opportunity to move over. Before actually doing so, it will verify that the lane is clear, that there are no other non-communicative cars, and that my car indeed slowed down to make the turn. By having multiple directional antennas on the receiving vehicle, it can tell precisely where the transmitter is, just as well as a driver looking out of the window.
The V2V system is not really intended to be treated as a paragon of truth. It can assist, but it's really just another input to another car-driving system, whether automated or human. To a human, the V2V information can be projected on the windshield as a HUD, for example, marking expected paths for nearby communicative cars. For an automated system, the V2V information can be used to plan routes with more certainty than prediction algorithms plotting likely paths based on traffic and behavior alone.
If it were true that long-term low level radiation were unquestionably harmful, you'd expect to find a clear negative trend.
No, that's not what we'd expect to find at all.
We'd expect to find at the high end a certain level of radiation that is absolutely lethal, and as the dose is reduced, the impact would drop down steadily, until a zone where life expectancy is reduced. However, that life expectancy is more or less on an absolute scale, and must be compared to the life expectancy of the species being exposed. An insect may survive high doses of radiation simply because it wouldn't normally live long enough to exhibit symptoms, while a longer-lived animal like a human will likely survive long enough to get cancer that ultimately causes death.
At a very low dose, the chances of having any noticeable symptom from radiation is unlikely enough that it could equally likely be caused by millions of other factors, so usually nobody cares. There is still a negative trend in survivability, but it's dwarfed by all of the other fatal conditions.
Too little radiation and the species dies due to inability to keep pace with changing environmental conditions.
Radiation isn't the only mechanism for mutation, though. Rather, it's the fast and cheap way to make a lot of mutations really fast, usually in places that cannot possibly contribute to evolution.
In order to change the species, an offspring's DNA must be mutated. That's dependent on a few thousand cells out of the trillions in a human body. Those particular cells are the ones involved in meiosis, splitting and reassembling the DNA that will become half of the offspring. During that reassembly process is where most mutations happen, usually by random chemical processes rather than any radiation. This enzyme doesn't successfully react with that protein, so a gene gets skipped or altered or inserted... It is extremely rare that a gene is altered by radiation during the process.
Once an offspring's development begins, though, the effects of mutations become more pronounced. If radiation mutates a single cell during early stages of growth, that fetus will develop with a cluster of mutated cells. Unless those cells are destined to become a gonad, however, the mutation will die with that generation, and the species will not change.
Similarly, radiation affecting a mature individual is is unlikely to have any positive effect, as the mutation is almost always either destructive or irrelevant. The proper functioning of a human body requires millions of interactions between tens of thousands of proteins, so randomly changing one protein is more likely to break something than to add new functionality. Of course, as before, even breaking something is only going to affect the species if it happens to occur in a cell involved in reproduction.
It is important to remember that evolution is never towards anything. It is away from an inability to reproduce (usually due to death). As an illustration, you must realize that you are the result of an unbroken line of millions of ancestors dating back millions of years, and every single one of those millions of ancestors were fertile and successful in mating. There is no scorecard in evolution. Either you pass on your genes, or you don't. It doesn't matter if your changing environment caused you severe illness or discomfort. As long as you manage to find a mate and make a child, you've won the natural selection game.
In short, radiation is a purely random occurrence with purely random effects, and the odds of any particular radiation-caused mutation being beneficial are so absurdly small that it is absolutely safe to say that overall, there is no safe dose.
Slashdot Mirror
Only $340 to have a qualified technician disassemble a large electronic device, connect specialized repair equipment, and perform the repair, then reassemble the device again to meet original specifications, perform a functionality test, and recertify the device?
$30/hour for 10 hours (plus about 10% overhead) sounds pretty cheap, actually... or would you prefer that the cost of such repairs just already be worked into the cost of the initial product, which was sold several years ago and was perfectly suitable for its purpose during that time?
The big lie about modern electronics is that they're easily repairable.
Yes, the TV in question can be repaired. Mr. Cauthon can disassemble the thing, remove the boards, desolder the flash memory, attach it to a reader/programmer, change bits to match a known-good unit, then rebuild the entire thing to see if it works. It's not going to be easy, but it will work... Of course doing it that way would cost a lot more than just replacing the board with a spare and resetting the memory, so that's what the service center will actually do.
Of course, all of that work really should be done in an ESD-safe environment, with clean air and properly-trained technicians. While a random software engineer might have the tools and ability to do the work, it's very unlikely that the repair quality could be good enough for LG to accept any remaining warranty (explicit or implicit) on the unit, which they may be legally obligated to do if they provide assistance.
It's easy to forget just how fragile electronics actually are. We are used to consumer goods, which have been designed specifically to handle the stress of normal use, but after the initial manufacturing, it's just not cost-effective to do troubleshooting and repair work with such delicacy. It's much easier to just replace what's replaceable with newly-manufactured parts, fresh from the mechanized assemblers that can handle such precision.
...just like guns "can be exploited" to shoot people, and vehicles "can be exploited" to run over them.
It's a very dangerous argument you're making, that liability is derived from the end condition, rather than the initial effort. As long as LG put forth a reasonable effort to ensure that their products are free from defects, which seems likely considering the product timeline, LG is very unlikely to be at fault here.
I'll also note a bit from TFA:
It is unclear at this moment if Cauthon's relative downloaded an app from the official Play Store, or from a third-party source.
There will be no more automatic speed boosts.
The reason there were jumps before as the die size decreased was that the semiconductors took less time to change states, so they could switch faster. Now, though, the parts are getting close enough together that quantum tunneling becomes a major problem, and increases in switching speed are accompanies by a drastic increase in error rates. We can still make the features smaller, but increases in speed will likely be counteracted by increases in required stabilization time.
Rather, the biggest areas for future work are in parallelism and prediction. At the cost of complexity and chip area, we will see more predictive computations, optimizing the slowest operations into little more than lookup tables. We can also expect to see more bus channels added to chips, which in turn will give far greater I/O capability. Similarly, expect to see more features built into chips, moving toward desktops being essentially a SoC with a breakout board.
In short, we've reached the point where raw clock rate increases are extremely difficult for only marginal gains. Increases in speed, however, are sill promising, but they come from making better use of the cycles we have.
There is simply no way to ... enforce contractual terms after money has changed hands.
Well, fortunately that opinion was obsolete about 5000 years ago, when debt contracts became legally enforceable. Because we can legally oblige someone to follow terms after an exchange of money, we as a society developed investment, credit, loans, and complex economics. Effectively, if all exchange was limited to what was available at the time of the transaction, we'd be trapped in a barter economy.
Your rejection of the law and assertion that it cannot possibly be exactly how it's been for millenia does not in any way change the fact that the law exists and has worked very well overall.
While we're at it, let's discuss the other points you've fumbled.
You might as well try and justify child labor...
Which, when legal, is legal and justifiable. It didn't magically become illegal just because decided it was immoral. Rather, it was legal prior to any laws outlawing it, and continued to be legal until there were new laws declaring that children were not legally employable. That had some major side effects, like disruption to family businesses, so the laws were clarified to grant limited exceptions where the child's parents consented on the child's behalf. That led to more problems in cases where the parents did not care about their children's well-being, so the laws were again adjusted to the form we have today, where it is a complex set of rules to determine a minor's eligibility for hire.
Making a blanket law like "all minors are unemployable" is a very short-sighted reaction to the problem, and leaves you with the problem of starving farmers whose kids can't help harvest the crops. Good luck justifying that.
...and indentured servitude
...which is a very interesting application of contract law. At the time, indentured servitude was a simple contract: I give you X, you work for me for Y years. The unfortunate downside to that was that during those years, you couldn't do anything else to support yourself. This led to laws that contracts must not leave either party destitute, such that they would be unable to live reasonably during or after the contract. Once those laws were enacted, indentured servitude quickly gave way to employment contracts, that usually specified the same deal as the servitude, but with livelihood provided during the term of indenture.
Notably, an employment contract is a contract. You agree to certain conditions (working), and the employer agrees to conditions (payment). If you quit the job, the contract might say you have to pay back your wages or meet other demands, and they'd be enforceable, too. The contract could prohibit you from working in the same industry for the remainder of your contract term, and it'd be enforceable.
Since a key aspect of a contract's consideration is that you are giving up certain rights of your own, the contract may supersede other laws. This is now coming into play for EULAs and service agreements, as arbitration clauses are being included in the contract, overriding local laws regarding dispute resolution. The debate in the courts is whether your right to a court-based resolution is waiverable by a contract or not. There have been decisions on both sides, so the matter is not yet settled.
They're no different from those "employee handbooks" that have a little notice at the end saying that the handbook is not an employment contract.
That's correct. They are not contracts, which means that they do not invoke contract law over any other laws that are in place. That's very important, because it means that nothing in the handbook is binding by contract law.
Without the handbook being a contract, the law falls back to whatever would be in force without the handbook's existence. Usually, that's a law saying something to the effect of "the employer wil
Firstly, "click to accept" has been upheld many times, It's been overturned on a few rare occasions, in instances where other circumstances (like local sales laws) invalidated the EULA conditions.
1) In the particular case in this discussion, writing the airline with new terms would immediately be laughed out of court. It's not the normal method of doing business, and the AC proposing the scheme stated that he knows the airline has no process to handle the proposed contract, so the contract is obviously being made in bad faith.
2) In a service contract, if the terms change there is a window (typically 30 days, but it depends on the jurisdiction and applicable, consulmer protection law) during which you can cancel the service or otherwise reject the new terms (though that usually triggers other terms in the contract, like cancellation). However, it's important to note that a previous contract already exists. That changes the legal posture significantly. Again, in the case of sending your own terms to an airline, there's no pre-existing relationship, and your case would be thrown out of court pretty quickly.
It depends on the terms of the EULA, and the implementation, and ultimately what it can convince a judge to decide.
The basis of a contract is that both parties are giving up legal rights in exchange for others. As an example, in a EULA the publisher is giving up certain exclusivity to copying, and you are giving up rights to privacy, warranty, and a chunk of money. Yes, the contract can also include escape clauses that define the actions (like failure to maintain a support contract, or failing to run updates, or clicking the "I don't accept" button) that will terminate the contract, and may entitle you to compensation (like a refund).
The legal complication comes from software that requires exercising the contract rights (copying to RAM) before seeing the EULA. In the case of installers and online services, and the infamous "by breaking this seal" stickers, that's a problem, and that's what some courts have decided against. The only real result is that now, EULAs are written to separate pre-EULA actions from the contract terms, so you can view the EULA before accepting, but still can't really use the software without accepting.
No, the courts did not invalidate contracts en masse. They just closed a loophole in a few specific cases, where the contract terms didn't mesh well with the actual system behavior.
If you write back and they don't do anything to explicitly accept the new terms, they're generally unenforceable. You buying the ticket (or installing software, or using a service) is an action that indicates you accept their contract. Actions can accept contracts. Inaction generally cannot.
Eh..... not so much.
"Alternative right" and "conservative" are not really synonymous. The term "alternative right", often shortened to "alt-right", was coined by a white supremacist to distinguish his movement from the more traditional conservative views.
Broadly generalizing, the focus of the typical conservative is economic strength, usually through privatizing services and promoting individual liberty, within the limits of societal conformity. The alt-right emphasizes the conformity to the exclusion of other races and ideologies, with any economic efforts coming secondary, as they are seen as being more easily manageable once white supremacy is established. It is most easily contrasted with the Libertarian label, which typically emphasizes the economic principles while minimizing the social aspects.
No, not everyone who fits the "alt-right" category fits the "neo-Nazi" category, but there is significant overlap, especially (as crypticedge's comment mentions) in the Trump-supporting sections of 4chan. There are some alt-right folks who try to stay away from neo-Nazism, but 4chan's preference for anonymity makes it very difficult to isolate that distinction in the community.
No, it's not about "labeling and demonizing by the Left". The left-leaning folks who are inclined towards demonizing already compared conservatives to Nazis. Rather, the new prevalence of neo-Nazi and alt-right labeling is coming mostly from those who align with the more traditional conservatism, in an effort to separate themselves from the white supremacist (and other) controversies.
I'm going to have to disagree.
The groups that get the neo-Nazi label are the ones promoting Nazi propaganda, ideals, and methods. There are groups actively using the swastika symbol as an identity and using Hitler's writings as a doctrine. They advocate the same racial cleansing the old Nazis did, and the same totalitarian fascism. They get the name neo-Nazis, because they only differ by being more recent.
No, the label is not disrespectful to victims of the Nazis. Rather, what is disrespectful is to immortalize the Nazis by granting them some kind of unique status as the gods of oppression and death. By insisting that nobody today could compare to the Nazis, we further distinguish the Nazis as being something special, more powerful than mere mortal humans. In effect, declaring the Nazis as an untouchable evil would grant them status as a superior race, exactly as they wanted.
That would be disrespectful. That would undermine the victory of World War II. That would be an incredible disservice to each and every victim of the actual Nazis.
I'm not going to do that.
I'm going to continue to declare that any group that tries to act like the Nazis are neo-Nazis. I'm going to continue to treat them as humans; no more and no less. I'm going to continue to do what I can to ensure that the horrors of the Nazis are always presented as a mundane evil that got out of control, and I'm going to continue to teach that every person, everywhere, has that same capacity for evil, regardless of race, ethnicity, gender, sexuality, or economic status. They also have the same capacity for good, and it is the active choice to work toward that good that makes someone worthy of a unique place in history.
Today is the first time my gaming computer has been powered on in about two weeks, and I was able to launch DRM-protected games just fine in offline mode.
I'm not familiar enough with Steam's DRM to address your concerns about a token, but it does appear to work just fine in offline mode while offline.
As I understand TFS, there's a lot of doses available now that could be used to cover an outbreak, but those are not covered by full regulatory approval, and manufacturing capability is also probably rather low right now.
Once full approval comes through, in about a year, the vaccine would be generally available, and I would expect it to become part of the recommended treatment for anyone going to a risky area, as is currently the case with the yellow fever vaccine.
Well, that'd be great... but who's going to fund the synthesis of a plane-load of vaccine, and the training for a plane-load of qualified staff to administer it, and then also fund the two plane flights to Africa? You're asking for a few tens of millions of dollars, minimum... and that's not even considering the logistics involved in ensuring that the vaccines aren't immediately seized upon landing, and used as leverage in a civil war.
Maybe you think that the lab techs, nurses, pilots, maintainers, security personnel and diplomats should all just volunteer their time. That's nice, but then who's going to volunteer to feed them as well? Maybe you think the pharmaceutical company should just pay for everything, but they already do a lot of that, and that's partly why American medicine prices are so high.
...or maybe you just have no idea how the world works, and just want to enrage Slashdot readers.
Steam is different... it's not your perfect ideal, but it's different from the abysmal pit we were headed for before Steam. Steam is a decent compromise between the anti-cheat and anti-piracy efforts of vendors, and the pro-consumer model apparently favored by you and others.
See, what I remember from my history is that those multiplayer games were full of cheaters and hackers, to the point where half of the game was figuring out whether your game was legitimate or not. I remember seeing casual piracy with cloned disks and hundreds of "backups" being passed around my networks. I also remember seeing the start of server-side games that lost functionality when their studio closed and their servers shut down. I remember the predictions that that would be the only effective way to combat piracy, and I remember reverse-engineering efforts claiming to ensure the longevity of games... and I remember their failures, too.
Steam is not perfect, but it is different... It mostly works.
...You know that site doesn't even exist any more, right?
Nations aren't American people, though.
Americans tend to care about "freedom". Not any particular freedom, mind you, but they cling to the fantasy story that they are somehow "free" in an abstract sense, and any limit on that freedom is a grave assault on their very essence. However, the more recent evolution of this philosophy has extended the concern to others' freedoms as well. The privacy advocates don't have anything to hide themselves, but they're sure that someone out there has horrible secrets they're trying to keep from the Big Bad Government. The civil rights advocates aren't being persecuted, but they're supporting those who are being persecuted. The gun lovers don't own bazookas or urban-assault weaponry, but they want to be absolutely sure someone else can get them.
International politics, on the other hand, looks a lot more like the stereotypical spaghetti westerns. Every nation is concerned primarily with their own interests, and everybody's just one sufficient excuse away from attacking someone else. Their cattle came too close to your territory? That must mean they're your cattle now. They cut down a tree you liked to look at? That must mean they owe you reparations. Their drunk belligerent son insulted your father? This calls for a duel to the death.
There are also the outlaws. There are certain countries who have caused more trouble than their existence is worth, and it'd probably be best if they were relieved of their sovereignty, but, they still have a few powerful friends. You can't just kill that guy who annexed your land, because you'd be dead yourself in short order.
Now, the UN is suggesting new rules. Continuing the metaphor, this is effectively the equivalent of the townsfolk coming together and agreeing to not breed coyotes. No, there's no real way to stop someone from breeding coyotes if they want to, but everyone else has said they don't want more coyotes around.
What this means is that there is a new excuse in town. If someone accuses you of coyote-breeding, they might use that as justification to steal your horse. If they can prove you're breeding coyotes, they might be able to get a posse to kick you off of your land and take it for their own. Your friends won't have much ability to protect you, because they don't want to be associated with a low-down dirty rotten coyote-breeder. With your allies gone and a bounty on your head, everyone with an opportunity will try to prove their commitment to the law by coming after you.
Of course, it's very difficult to claim that breeding coyotes is bad when one is already doing it themselves. This is exactly what happened with nuclear weapons. The United States had them, so we couldn't effectively ask everyone else to ban them. Right now, though, there's very little interest in fully-automatic lethal robots. Even drone strikes are commanded by a human, and there is significant political pressure to keep them that way. The closest we have to automated killing machines is the common land mine, whose use is finally banned or regulated by most countries. There are also IEDs, whose use is being publicized as an indiscriminate assault on civilians... and in response, the good guys of the world continue to hunt those dastardly villains to protect the innocent!
In the public perception, there is a huge difference between the freedom of people and the freedom of nations. Yes, a country bound by the UN rules could still create AI killers, but there are effective human-led counterattacks to them. There is no benefit to pursuing the prohibited weaponry.
So when you decide to mitigate the risk by bringing it all in-house, you can't.
There are reasons to bring infrastructure in-house, but risk mitigation isn't one of them. Your risk is mitigated by having an SLA with a provider whose primary function is to maintain those servers, with penalties attached for downtime to compensate for the loss.
For large projects at large firms such as those mentioned in the article (Walmart, Ford, etc), you need these types of people on hand anyway. Farming out shit "for convenience" isn't an excuse for being lazy.
No, those companies really don't need a devops sysadmin on hand. They need sysadmins in other areas, who can focus on those areas, but they don't need nearly so many supporting the development.
Sure it might cost more, but if you farm it all out your business will consist of workers who are jack-of-all-trades and master-of-none.
Really, it works the other way. If you farm out distinct areas of your infrastructure, the experts you have don't need to work in those areas, and they can specialize in the areas in which you do need in-house support.
A company I have worked at has reasons (some of them even decent) to have everything in-house, and as a result of that, my sysadmin team was highly fragmented. We had a dozen members, but were expected to support a dozen different efforts, so we had these guys who knew X well, those guys who knew Y well, this one guy who was a Linux expert, that guy who was a Windows expert... and as a result, we were effectively all on-call 24/7 because we were spread too thin. If any system broke, we had to first figure out who the expert was, and then contact them directly.
They're selling convenience.
Most software managers don't care too much if someone that can produce a NSL gets to see their source code. They are concerned about direct competitors having access, and they're concerned about having to pay sysadmins to handle the development environment. Sysadmin labor isn't cheap, and neither are the servers, storage, backups, auditing, or workflow tools that make development happen.
If your business is making software, you can just pay GitHub for that infrastructure, and focus on your software.
Have you not considered the possibility that the developer wanted different runtime guarantees than the standard library sort provided?
Yes, I have, and find it extremely unlikely that the programmer had any idea what he was doing. Mostly that analysis comes from the knowledge that the particular software package was an interface for a low-speed IO device, and could have probably have performed just fine if it relied on a bubble sort. Then again, I've also worked with the programmer responsible for that particular package, and it wouldn't surprise me to find that he had actually written his own bubble sort...
There are very good reasons to use something other than the bog standard quicksort with a heap sort fallback (aka introsort) in a lot of scenarios, be they server services or even games.
That's not really disputed, but there are third-party libraries that provide many sorting options, without having to write (and debug, and maintain) it yourself. If you have a very good reason to use a particular algorithm, find a library that provides it.
For either games or server services, that standard library introsort would never be used if I was head of the development team. No chance in hell does it perform better than radix sort (for game scenarios) or has the best possible worst case runtime (for server services.) Its a complete no-no to use it.
It sounds like you don't really know much about data processing scenarios. I once had a mentor who said something to the effect of "If you're thinking about your sorting, you're doing something wrong". The reality is that except for the most demanding applications (like rendering on the GPU), the programmer shouldn't need to think about what sorting algorithm is being used. Rather, the programmer's primary concern should be writing clean and maintainable software, and leave the exact implementation to someone else, who only needs to write according to an API specification. If that spec includes performance targets, then it will require particular algorithms. Otherwise, anything reasonably efficient will do the job, and it becomes a point of testing to compare different libraries for required functionality.
For example, let's consider the high-speed sorting used to render a 3D game world. The game programmer just needs to build the world in the game engine, and the engine will handle the sorting. The engine programmer only needs to worry about getting the data from the game library to the renderer, and the renderer will handle the sorting. The render engine programmer finally has to think about sorting algorithms... but his choices are driven primarily by the data structures present and the hardware optimization available, which may drastically change the run times of algorithms. With the appropriate hardware available, the render engine may pass off sorting to the GPU, using some of the SIMD processing capability to (for example) run a Batcher sort, rather than a radix sort on the CPU. I am told that's actually what nVidia's "game-ready" drivers do: They forcibly replace a game's poorly-optimized code with equivalents that use nVidia's hardware more effectively.
On the server side, I will refer to another aphorism: "Premature optimization is the root of all evil". If using a custom sorting method means moving data around outside of your database, you're not going to get a performance improvement. If you're concerned about worst-case performance because you might see it in real use, you should be thinking about security, not performance. If you're optimizing the application to improve user load performance, it's usually cheaper to just buy more hardware and run more back-end servers. In short, sorting is rarely the most effective target for optimization, so it's generally not worth the cost to improve, when efforts could be focused elsewhere.
> That's one of my criticisms of FOSS developers, they can be a bit crazy with their dependencies.
You know that because you can see them.
My day job involves creating itemized lists of dependencies for a very large project. I can assure you that both open- and closed-source software is horrible, though I do have to admit that open-source tends to be a bit worse on the unexpected-dependency front, for a few reasons.
In closed software, there is a lot of effort spent recreating common elements. I cringed when I found a file named "sort.dll", but it's probably exactly what it looks like: A developer didn't want to depend on outside code, so they wrote a sorting function as a library. Without an audit like mine, nobody would ever notice the silly practice of rewriting what's probably built into their language, and readily available in other third-party libraries.
Open-source software, then, is more transparent. If a FOSS project reimplements a sort, it will eventually be discovered and mocked until it uses the third-party library. This is fine, as it also reduces the complexity and size of the FOSS project. However, it does then lead to a bit of shock to see that the "widget" package depends on 53 other packages including "libfoo", "libbar-dev", "libbaz-ng-perl-1.03-sparc", and so on. Compounding that, it's also trivial for the FOSS project to actually use that library, because the library itself is likely FOSS, with a compatible license. Even if all your project needs is a single function, there's no cost to depend on an entire library... and a different one for a different small part, and so on.
The tendency to include a long list of dependencies makes my job worse for FOSS, because I can't just shrug my shoulders and give up after listing the one software package without any named dependencies. On the whole, however, it does ultimately lead to a smaller (and more traceable, and higher-quality) codebase for a final system, which is why the hardware requirements for a FOSS system tend to be much lower than an equivalent system based on closed-source packages.
Despite penalties, there are still those who spoof the traffic light priority systems used by emergency vehicles. There will be those who abuse this too. In general, this would be merely an annoyance.
I like that example, too. A commuter could claim to be an emergency vehicle, and expect other cars to move out of the way. Of course, that commuter would then be disappointed when the automatic systems ignore him because he lacks flashing lights, a siren, or a proper crypto certificate identifying him as an authorized emergency vehicle.
Existing systems widely use infrared beacons, which are easily spoofed. Newer systems actually have authentication between the vehicles (with onboard GPS tracking) and a central control server, and the server changes the lights as the authenticated vehicles approach. As technology and cryptography have improved, security has improved as well.
But what if this is used to control or effectively stop your vehicle? How long before police used it to stop vehicles?.
Probably never, because again the V2V system is designed to be advisory. If such a capability is built in, it is trivial to add authentication, such that (for example) only police who have received an authorization within the last hour to stop your car specifically will be allowed to stop your vehicle.
Or someone that wants to stop a woman on a deserted road.?
They'd need to be in a police car, with a valid standards-compliant certificate from a local jurisdiction authorizing them to access the car-stopping function, or their polite request would be rejected. To me, it sounds safer than just letting anybody with a light bar and a CB radio pull someone over.
The ne'er do wells could wreak havoc using this system.
Again, the ne'er-do-wells can already wreak havoc using existing systems. V2V only adds the possibility for authentication and information where there is no such capability today.
Exactly... this is the part that worries me... they talk about 128 bit encryption and all that jazz, but this isn't a negotiated connection people...
Eh, sort of... There are parts that are broadcasts, and parts that are connections. It gets complicated.
it's transmitting your telemetry in the blind, hoping that others will act on it.
Wait, no, stop. Let's clear this up right now: The transmitter doesn't care what you do with the information. It has absolutely no benefit solely from transmitting, which is why the government is stepping in to say "transmit, dammit!" Unfortunately, that invisible hand of the free market works against us here.
Rather, the V2V transmission is advisory, providing other vehicles the option to act on the provided information. That is one more option than we have now with non-transmitting vehicles, but like any other option, it will be validated and weighed against the other navigation options.
As such, everyone will be using the same encryption key, which will make it trivial for someone to transmit false information.
Not really. I'm not terribly familiar with the crypto for V2V, but it's pretty trivial to make a suitable encryption system. We need nonrepudiation (showing that a particular transmitter said a particular thing), authentication (showing that a particular message comes from a trusted source), and integrity checking (showing that a message was not altered). As noted by another commenter, PKI can provide all of those things. Essentially, each vehicle broadcasts beacons with its own decryption key, which is different from the encryption key it uses (and keeps secret). Telemetry messages are then sent with a plaintext vehicle identifier and an encrypted payload, and receivers just need to remember which decryption key belongs to which vehicle.
There are literally dozens of ways I can think to abuse this capability for fun and profit.
...and there are dozens of ways to counter them. It's easy to play armchair engineer and think of ways to abuse the system, but it's equally easy to find effective mitigations. In the decade or so that I've been following V2V technology, here are the most common ways to deal with attacks:
Firstly, since V2V is advisory, anything that doesn't make sense can be ignored. No, nefarious hackers won't be able to coerce your car into running through a crowd of schoolchildren. You'll have to do that yourself.
Second, as noted elsewhere, the system doesn't have to be perfect - only an improvement. At this very moment, there are literally dozens of folks driving slowly in the wrong lane with their blinkers on. That's bad information right there, and our current driving systems cope with it by recognizing the problem and working around it.
As a third foil against the most common complaints, the keys and identifiers don't have to remain attached to your vehicle forever. There have been test implementations that regenerate identifiers at every trip, or randomly while traveling easily (like down a straight highway). With few other cars around, it's even possible for your vehicle to turn off transmissions, and reappear later as an apparently-different vehicle. Effectively, the only way to track someone reliably is the old-fashioned way... physically staying in radio range.
The other issue is this: The expected range these operate at is defined by the size and quality of the antennas they intend to use, but with improved listening capability the range is much further.
Eh, sort of... but radio doesn't quite work that way. As you get further away and get a bigger antenna, the amount of noise (and other transmitters) also rises. Roughly speaking, the amount of noise rises linearly, and the strength of the signal drops off quadratically, according to the inverse-square law.
Even with a huge antenna, you won't be able to follow a single car very
Your colorfully-worded argument has convinced me that you have absolutely no idea what you're talking about.
Essentially, you argument is that the system can be used to tell vehicles false information. However, that's entirely possible today with the existing information systems. You can turn your blinker on without turning. You can randomly apply the brakes and slow down. You can weave through traffic, and disobey lane markings.
No, V2V is not going to replace common sense, or the algorithms in self-driving vehicles. If a car announces a planned path, it's not going to be trusted outright. Rather, it will be corroborated with reports from the receiving vehicle's sensor suite, other vehicles, and even fixed landmarks.
To illustrate, let's consider some example scenarios, where I will play the bad guy, with a significant technical ability, no morality whatsoever, and a strong desire to keep noisy traffic off of my quiet little street. For ease, we'll assume no functioning cryptography, focusing only on algorithmic security.
It would be pretty easy for me to make a little beacon to announce that my road's under construction. However, with no construction cones nearby, no proper roadsigns, and no road crew, vehicles would have little reason to trust my beacon. They might put a little more weight into their road sensors looking for potholes, but that's about the extent of my influence. Of course, I could post some fake construction signs, but that's illegal under current law, and the only difference is that I would be adding a radio announcing to the police that I've put up fake signs.
Let's get a little more malicious. I could spoof two vehicle transmitters, announcing an accident. Surely, traffic will route around it for a while, but eventually something will come down my road anyway, and notice that my transmitters' announced locations don't actually correspond to vehicles. In fact, it sees the road is clear, and announces that observation on the network. That causes another vehicle (which would really prefer my road anyway) to try driving past, and it corroborates the report, announcing that my transmitters are liars. Their spoofed vehicle IDs, then get flagged as fraudulent, and I have police coming to my door.
If I'm going to end up with a visit from the police eventually, I can at least make it interesting, and get the FCC involved. I can just jam all V2V traffic in my area, making my road an unknown compared to the safer routes around me. That may work for a while, but it doesn't deter any traffic that would have normally gone down my road. Without V2V communication, the vehicles fall back to their normal radar and vision sensors.
Now let's suppose I get really angry, and head out on the highway to wreak havoc. I can announce that I'm moving perfectly fine, going straight ahead. I can announce that my brakes are in great condition, that I have a full sensor suite, and all my data is trustworthy. I can announce a few spoofed vehicles just out of sight that trust my data. Everything says it's safe to come close to me, and nothing will go wrong... until I slam on my brakes. Then, the car behind me slams on his brakes automatically, because it rightly knows not to absolutely trust anything coming from V2V, and it's still watching my car with forward sensors. It also announces to the network that we're stopping, so all the cars for a mile behind me brake, too, and the ones that can shift lanes will escape. Even if there is a collision, the damage will be minimized by the slower speed and rapid self-preserving coordination. The flood of messages about the delays will be weighed more heavily than my fake announcement of clear conditions, so the affected lane will be avoided, and vehicles will move away as they're able. I've disrupted a few folks' smooth sailing, but it's not catastrophic.
No, the system isn't perfect, and it's not designed to require perfection. The people actually doing V2V work are well aware of the limitations of network communications, and are designing systems to work around malicious actors. In the worst cases, it's still better than human drivers or isolated automatons, so it's still a net benefit.
1. Triangulation, self-identification, and multiple sensors.
2. Multiple sensors.
There's a common thread here.
Any V2V system is advice-only. My car can advise other cars that I'm in this particular place, and I'll be turning right up ahead. That lets the car to my left know that I will be getting out of its way, and it will have an opportunity to move over. Before actually doing so, it will verify that the lane is clear, that there are no other non-communicative cars, and that my car indeed slowed down to make the turn. By having multiple directional antennas on the receiving vehicle, it can tell precisely where the transmitter is, just as well as a driver looking out of the window.
The V2V system is not really intended to be treated as a paragon of truth. It can assist, but it's really just another input to another car-driving system, whether automated or human. To a human, the V2V information can be projected on the windshield as a HUD, for example, marking expected paths for nearby communicative cars. For an automated system, the V2V information can be used to plan routes with more certainty than prediction algorithms plotting likely paths based on traffic and behavior alone.
If it were true that long-term low level radiation were unquestionably harmful, you'd expect to find a clear negative trend.
No, that's not what we'd expect to find at all.
We'd expect to find at the high end a certain level of radiation that is absolutely lethal, and as the dose is reduced, the impact would drop down steadily, until a zone where life expectancy is reduced. However, that life expectancy is more or less on an absolute scale, and must be compared to the life expectancy of the species being exposed. An insect may survive high doses of radiation simply because it wouldn't normally live long enough to exhibit symptoms, while a longer-lived animal like a human will likely survive long enough to get cancer that ultimately causes death.
At a very low dose, the chances of having any noticeable symptom from radiation is unlikely enough that it could equally likely be caused by millions of other factors, so usually nobody cares. There is still a negative trend in survivability, but it's dwarfed by all of the other fatal conditions.
Too little radiation and the species dies due to inability to keep pace with changing environmental conditions.
Radiation isn't the only mechanism for mutation, though. Rather, it's the fast and cheap way to make a lot of mutations really fast, usually in places that cannot possibly contribute to evolution.
In order to change the species, an offspring's DNA must be mutated. That's dependent on a few thousand cells out of the trillions in a human body. Those particular cells are the ones involved in meiosis, splitting and reassembling the DNA that will become half of the offspring. During that reassembly process is where most mutations happen, usually by random chemical processes rather than any radiation. This enzyme doesn't successfully react with that protein, so a gene gets skipped or altered or inserted... It is extremely rare that a gene is altered by radiation during the process.
Once an offspring's development begins, though, the effects of mutations become more pronounced. If radiation mutates a single cell during early stages of growth, that fetus will develop with a cluster of mutated cells. Unless those cells are destined to become a gonad, however, the mutation will die with that generation, and the species will not change.
Similarly, radiation affecting a mature individual is is unlikely to have any positive effect, as the mutation is almost always either destructive or irrelevant. The proper functioning of a human body requires millions of interactions between tens of thousands of proteins, so randomly changing one protein is more likely to break something than to add new functionality. Of course, as before, even breaking something is only going to affect the species if it happens to occur in a cell involved in reproduction.
It is important to remember that evolution is never towards anything. It is away from an inability to reproduce (usually due to death). As an illustration, you must realize that you are the result of an unbroken line of millions of ancestors dating back millions of years, and every single one of those millions of ancestors were fertile and successful in mating. There is no scorecard in evolution. Either you pass on your genes, or you don't. It doesn't matter if your changing environment caused you severe illness or discomfort. As long as you manage to find a mate and make a child, you've won the natural selection game.
In short, radiation is a purely random occurrence with purely random effects, and the odds of any particular radiation-caused mutation being beneficial are so absurdly small that it is absolutely safe to say that overall, there is no safe dose.