Many jobs are nonessential up until they aren't. For example, you don't need the people who inspect aircraft repairs or nuclear power plant repairs to be there every minute of every day, but if they don't do their jobs for a long enough period of time, you get consequences.
Open-source documentation is like an insomniac cat. Theoretically it exists somewhere, but no one's ever seen it.
Cats are night hunters, so arguably they're all insomniacs. Perhaps you meant an invisible cat?
Either way, that's not a very accurate analogy. Open Source documentation usually does exist. It just tends to be incomplete, and focused on what was considered important at the time it was written, most of which no longer applies to the current version of the software. It also tends to be written from the perspective of someone who already understands all the details of the software, because almost by definition the people who wrote the code also wrote the docs. With few exceptions, this results in docs that are hard to understand unless you already know enough that you don't need to look at the docs in the first place.
The biggest thing most Open Source projects need to do is get someone other than the engineer to write the docs. At a very minimum, have someone create a quick-start doc, then give it to somebody who has never used the tool and see if that person can follow it. Repeat until good enough.
Watching your every move, but still allowing you to do whatever it is you do, so long as it's perfectly legal, might conceivably satisfy the restrictions that the fourth amendment imposes.
Not really. If a warrant is required for any otherwise unreasonable search, then by definition some searches must be unreasonable. What you describe is a situation in which all searches are reasonable, effectively nullifying that right.
And if you limit it only to evidence that does not prove guilt, then either all evidence is useless in a court of law or serves only to provide reasonable cause to obtain a warrant to collect other evidence. The problem is that they could then potentially use it to obtain a warranted copy of the same evidence, which would be just plain absurd, as it would effectively nullify the warrant requirement once again. And, of course, if it is useless, then there's no logical reason to obtain it in the first place, which makes the collection inherently unreasonable.
Either way, that's just not a plausible interpretation of the fourth amendment.
WarGames, ignoring the suspension of disbelief regarding an artificially intelligent computer, didn't have many truly egregious technical implausibilities. The ones I caught were mostly pretty subtle, like the dubiousness of wardialing with an acoustic coupler.
Contrast WarGames: The Dead Code, which had dozens of technical inaccuracies—about one every couple of minutes—that were so glaring that they should have been obvious even to a casual observer... like drones that could fly all the way across the country without refueling. I've repressed most of the details because it just hurt too much.
Considering that the design of the ACA is based almost entirely on a bill that Mitt Romney and his Republican friends pushed through at the state level, that has to be the most disingenuous thing I've ever read, period. The ACA barely even resembles what the Democrats originally wanted, and is remarkably close to what Republicans said that they wanted. The way that the Republicans voted on the actual House/Senate floor is largely immaterial.
Weird, indeed. According to WIkipedia, Kentucky has had only eight Republican governors in its entire history... and curiously, only six Republican lieutenant governors. So in gubernatorial races, Kentucky is very solidly a blue state, historically.
Herd immunity still doesn't trump individual control of their body (at least IMHO). First, herd immunity is imperfect, secondly unvaccinated persons are rare thus making the argument even less cogent.
If unvaccinated people were truly rare and evenly distributed, it wouldn't be a concern. Unfortunately, unvaccinated people tend to come in clusters, usually because one person gets the notion that vaccines are harmful into his/her head and then spreads that to others like a wildfire. Then suddenly you have a community with a significant number of people who aren't immunized, and people die.
Worse, as I understand it, the more people who, upon exposure to the real virus, don't shut it down hard, the greater the risk of a mutation that reduces the effectiveness of the vaccination for everyone.
s/even/only/. You can get shingles only if you have previously had chicken pox. If you haven't, and if you get exposed, you get chicken pox, not shingles. Shingles is just the long-dormant virus becoming active again.
"Cadillac is touting the ELRâ(TM)s 8-inch touchscreen powered by its CUE infotainment system â" which two years in is still a buggy mess"
Technology that is badly designed and doesn't work properly isn't a selling point.
Technology that is fundamentally defective by design and can't work properly isn't a selling point. Who in their right minds wants a touchscreen-controlled anything in a car? That's exactly the opposite of making cars safer. You can't control a touchscreen without taking your eyes off the road for an extended period of time.
Touchscreens have no place in the front section of a car unless they are mounted to the left corner of the dashboard so that at least you're roughly looking at the road.
True. I'm not saying the punishment in Saudi Arabia is reasonable, either; I'm merely saying that the fact that there was some form of punishment shouldn't shock anyone.
Simple. It's because the moment someone slaps a sustainable or sweatless sticker on their E-product, people are going to start looking at where the caps, commodity chips and resistors come from. Are the components 100% made without slave labour?
Yes and no. When you move manufacturing to a country where workers are treated better, the component manufacturing tends to follow, because it is generally cheaper to source parts locally than to ship them halfway around the world. So no, you can't guarantee every component immediately, but at least you're pushing the boulder in a way that would cause it to pick up speed as it rolls downhill towards that ideal goal.
I'm pretty sure that assembly line work isn't going to improve their prospects much.
That's not necessarily true.
If these are hardware engineering interns, then spending a day or two working every position in the assembly line for a short period of time could be a valuable job skill. By letting them see firsthand what parts of the design are assembled easily and what parts aren't, they would have a better idea of what works and what doesn't (and why), which might actually make them better design engineers.
Similarly, if their internship is in manufacturing management, then seeing what workers have to do can make them better able to understand the challenges that their future employees will face.
If, on the other hand, they're spending a month doing it, or if their internship is in an area other than hardware design or manufacturing management, then yeah, they're just getting screwed.
That said, dancing naked on the hood of a car—presumably in public—violates even America's public morality standards, and can get you jail time for indecent exposure.
That was actually my conclusion as well. How do we know that the person they executed was, in fact, the king and not a royal double? Finding someone who looks enough like the king to fool the peasants in the event of a revolt has been a time-honored tradition among royalty for centuries.
Maybe it was a long-lost ancestor of Mel Brooks.:-D
That's the responsibility of the site admin, not the software writers.
No, it really isn't. Software that can overwrite the configuration arbitrarily without authentication simply does not belong in a location where it can be executed remotely. That's a serious flaw in the software (and one that is shared with lots of other similar software). At a bare minimum, the install suite should immediately detect that a configuration file exists and should refuse to restart the install until the admin logs in via the shell and moves the config file aside.
But for real security, I'd go one step further. The install tools should be a set of scripts that live outside the web root and are run locally by the user on the command line, rather than using a web UI to do the initial setup. Any design in which the setup process could be simultaneously performed by more than one person results in an inherent race condition in which someone could hijack the site and add a second admin account during the initial configuration process, and you might never even know that it happened.
No, this is unsafe by design. Software should be safe by design in its default (untouched) configuration. This violates proper software security practices pretty egregiously. Yes, the admins should have read the directions, but that doesn't mean that the software writers are blameless by any stretch of the imagination.
People staying at budget and midscale hotel chains are more price sensitive, so they're going to not come to your hotel if you don't have free wifi. The people staying a luxury hotels are not as price sensitive and are more likely to be worried about other things beside a charge for internet access when selecting a hotel.
Put a bit more cynically, those high-priced hotels cater to people who have no concept of the value of money, and show their contempt for their customers' financial skills at every possible opportunity. The problem is, a lot of those folks end up at those hotels because some travel agency booked them there in a block along with the rest of their tour group. Those folks are pretty unhappy about it.
These days, I just make sure I have enough of a data allowance on my phone so that I don't have to care about the Internet service at hotels, under the assumption that half of them will want to extort money for Internet service and half of the remaining hotels won't have service that actually works. It really doesn't make sense to spend ten bucks per day for Internet service on a ten-day trip when you could spend ten or fifteen bucks for 30 days and a gigabyte of cellular data.
No, they'd also have lots of cool effects where text is flying all around their screens and they would use a l33t cracking tool called WhoIS to find out who really owns a domain.
Depending on what you mean by "physics engineer", there's a good chance he/she will use one as a data source, albeit usually a fairly simple one. Accessing a database table is easier than parsing a flat file, generally speaking. A graphics engineer either falls into that "mostly down at the kernel level" category or will end up reading model data blobs from a database for some project eventually. And a web dev doing the JavaScript side needs to at least understand enough about what's happening under the hood to be able to ask good questions and understand why only certain things are possible. Mind you, these are very basic uses of a database, and require only the most lightweight understanding of how things work.
Nobody who isn't deploying servers needs to understand data replication. That's a tiny niche area in the database world. Similarly, most people don't need to know concurrency details. That said, I think everyone should at least understand the basic concepts—tables, primary keys, normalization, etc.—and the easiest way to learn those concepts is by interacting with an actual database.
IMO, a function should be as long as it needs to be, and no shorter or longer. If the most easily understood way to express a concept is as a 5,000 line function, then you should write a 5,000 line function. Splitting up a function based on some arbitrary length limitation can only lead to less readable code.
For example, my record is almost 5,500 lines. The entire function is basically a giant switch statement in a parser (post-tokenization). The only way you could make that function significantly shorter would be to shove each case into a function, and all that would do is make it harder to follow the program flow through the function for no good reason. At any given moment, you're still going to be staring at exactly one of those cases per token (plus a little code on either end), so having each case in a separate function just adds execution overhead without improving readability, and it makes debugging harder because you now have to pass piles of flags around everywhere instead of just using a local variable.
One of the data structures for the function in question is almost 1200 lines long by itself (including anywhere from two to fifteen lines of explanation per field, because I wanted to make sure this code is actually maintainable). By itself, the initializer for that data structure cannot meet your "fits on one screen" rule, even with most of the fields auto-initialized to empty. And there's no good way to shrink that data structure. It is a state object for a very complex state machine. The code to interpret the end state is over a thousand lines of code by itself.
In short, those sorts of rules simply don't make sense once the problem you're trying to solve becomes sufficiently complex. They're useful as guidelines for people who don't know how to write code yet—to help them avoid making obscenely complex functions when the functionality is reasonably separable into smaller, interestingly reusable components, to keep themselves from shooting themselves in the foot by repeating code where they should call a shared function, and so on. However, IMO, if you're still thinking about rules by a few years out of school, they're probably doing you more harm than good, causing you to write code with unnecessary layers of abstraction for the sake of abstraction.
Well he's already failed. Databases are a niche topic that doesn't belong in an "uncontroversial" list of things that every software engineer needs to know.
When it was part of our CS required curriculum, I suspected I would never use it, but it turns out that the vast majority of projects I've been involved with have used databases in some way, and one of them even involved some pretty serious database query optimization. As far as I can tell, unless you pretty much code exclusively down at the kernel level, you're going to eventually be asked to work on some project involving databases. They're the glue that holds technology together. Outside of a handful of niche fields, I'd be surprised if any programmer managed to go more than five years out of school without having to work with one.
Also, once you understand databases conceptually, everything starts to look like a special case of a database. This is a good thing. C data structures? Table records. Pointers? Relations. And so on. It ends up helping you understand complex problems even if you're one of those rare people who never ends up touching an actual database.
Actually, it is. Electronic gauges don't typically stick. Don't get me wrong, a mechanical backup should be mandatory so that an electronics failure doesn't result in being unable to get readings at a critical moment, but using them as the primary readout mechanism is a recipe for disaster.
Slashdot Mirror
Many jobs are nonessential up until they aren't. For example, you don't need the people who inspect aircraft repairs or nuclear power plant repairs to be there every minute of every day, but if they don't do their jobs for a long enough period of time, you get consequences.
Cats are night hunters, so arguably they're all insomniacs. Perhaps you meant an invisible cat?
Either way, that's not a very accurate analogy. Open Source documentation usually does exist. It just tends to be incomplete, and focused on what was considered important at the time it was written, most of which no longer applies to the current version of the software. It also tends to be written from the perspective of someone who already understands all the details of the software, because almost by definition the people who wrote the code also wrote the docs. With few exceptions, this results in docs that are hard to understand unless you already know enough that you don't need to look at the docs in the first place.
The biggest thing most Open Source projects need to do is get someone other than the engineer to write the docs. At a very minimum, have someone create a quick-start doc, then give it to somebody who has never used the tool and see if that person can follow it. Repeat until good enough.
Not really. If a warrant is required for any otherwise unreasonable search, then by definition some searches must be unreasonable. What you describe is a situation in which all searches are reasonable, effectively nullifying that right.
And if you limit it only to evidence that does not prove guilt, then either all evidence is useless in a court of law or serves only to provide reasonable cause to obtain a warrant to collect other evidence. The problem is that they could then potentially use it to obtain a warranted copy of the same evidence, which would be just plain absurd, as it would effectively nullify the warrant requirement once again. And, of course, if it is useless, then there's no logical reason to obtain it in the first place, which makes the collection inherently unreasonable.
Either way, that's just not a plausible interpretation of the fourth amendment.
WarGames, ignoring the suspension of disbelief regarding an artificially intelligent computer, didn't have many truly egregious technical implausibilities. The ones I caught were mostly pretty subtle, like the dubiousness of wardialing with an acoustic coupler.
Contrast WarGames: The Dead Code, which had dozens of technical inaccuracies—about one every couple of minutes—that were so glaring that they should have been obvious even to a casual observer... like drones that could fly all the way across the country without refueling. I've repressed most of the details because it just hurt too much.
Considering that the design of the ACA is based almost entirely on a bill that Mitt Romney and his Republican friends pushed through at the state level, that has to be the most disingenuous thing I've ever read, period. The ACA barely even resembles what the Democrats originally wanted, and is remarkably close to what Republicans said that they wanted. The way that the Republicans voted on the actual House/Senate floor is largely immaterial.
Weird, indeed. According to WIkipedia, Kentucky has had only eight Republican governors in its entire history... and curiously, only six Republican lieutenant governors. So in gubernatorial races, Kentucky is very solidly a blue state, historically.
If unvaccinated people were truly rare and evenly distributed, it wouldn't be a concern. Unfortunately, unvaccinated people tend to come in clusters, usually because one person gets the notion that vaccines are harmful into his/her head and then spreads that to others like a wildfire. Then suddenly you have a community with a significant number of people who aren't immunized, and people die.
Worse, as I understand it, the more people who, upon exposure to the real virus, don't shut it down hard, the greater the risk of a mutation that reduces the effectiveness of the vaccination for everyone.
s/even/only/. You can get shingles only if you have previously had chicken pox. If you haven't, and if you get exposed, you get chicken pox, not shingles. Shingles is just the long-dormant virus becoming active again.
Technology that is fundamentally defective by design and can't work properly isn't a selling point. Who in their right minds wants a touchscreen-controlled anything in a car? That's exactly the opposite of making cars safer. You can't control a touchscreen without taking your eyes off the road for an extended period of time.
Touchscreens have no place in the front section of a car unless they are mounted to the left corner of the dashboard so that at least you're roughly looking at the road.
True. I'm not saying the punishment in Saudi Arabia is reasonable, either; I'm merely saying that the fact that there was some form of punishment shouldn't shock anyone.
Yes and no. When you move manufacturing to a country where workers are treated better, the component manufacturing tends to follow, because it is generally cheaper to source parts locally than to ship them halfway around the world. So no, you can't guarantee every component immediately, but at least you're pushing the boulder in a way that would cause it to pick up speed as it rolls downhill towards that ideal goal.
That's not necessarily true.
If these are hardware engineering interns, then spending a day or two working every position in the assembly line for a short period of time could be a valuable job skill. By letting them see firsthand what parts of the design are assembled easily and what parts aren't, they would have a better idea of what works and what doesn't (and why), which might actually make them better design engineers.
Similarly, if their internship is in manufacturing management, then seeing what workers have to do can make them better able to understand the challenges that their future employees will face.
If, on the other hand, they're spending a month doing it, or if their internship is in an area other than hardware design or manufacturing management, then yeah, they're just getting screwed.
That said, dancing naked on the hood of a car—presumably in public—violates even America's public morality standards, and can get you jail time for indecent exposure.
That was actually my conclusion as well. How do we know that the person they executed was, in fact, the king and not a royal double? Finding someone who looks enough like the king to fool the peasants in the event of a revolt has been a time-honored tradition among royalty for centuries.
Maybe it was a long-lost ancestor of Mel Brooks. :-D
No, it really isn't. Software that can overwrite the configuration arbitrarily without authentication simply does not belong in a location where it can be executed remotely. That's a serious flaw in the software (and one that is shared with lots of other similar software). At a bare minimum, the install suite should immediately detect that a configuration file exists and should refuse to restart the install until the admin logs in via the shell and moves the config file aside.
But for real security, I'd go one step further. The install tools should be a set of scripts that live outside the web root and are run locally by the user on the command line, rather than using a web UI to do the initial setup. Any design in which the setup process could be simultaneously performed by more than one person results in an inherent race condition in which someone could hijack the site and add a second admin account during the initial configuration process, and you might never even know that it happened.
No, this is unsafe by design. Software should be safe by design in its default (untouched) configuration. This violates proper software security practices pretty egregiously. Yes, the admins should have read the directions, but that doesn't mean that the software writers are blameless by any stretch of the imagination.
Besides build crappy printers that (at least in my experience) have major banding problems?
Put a bit more cynically, those high-priced hotels cater to people who have no concept of the value of money, and show their contempt for their customers' financial skills at every possible opportunity. The problem is, a lot of those folks end up at those hotels because some travel agency booked them there in a block along with the rest of their tour group. Those folks are pretty unhappy about it.
These days, I just make sure I have enough of a data allowance on my phone so that I don't have to care about the Internet service at hotels, under the assumption that half of them will want to extort money for Internet service and half of the remaining hotels won't have service that actually works. It really doesn't make sense to spend ten bucks per day for Internet service on a ten-day trip when you could spend ten or fifteen bucks for 30 days and a gigabyte of cellular data.
No, they'd also have lots of cool effects where text is flying all around their screens and they would use a l33t cracking tool called WhoIS to find out who really owns a domain.
The mice were mentioned in the "department" line, so we assumed we'd be modded redundant. But as long as we're going down that path....
Ooh. I know this one. The computation stops when we get bulldozed to make room for an intergalactic superhighway.
Actually, I think this is just Skynet fighting back. It doesn't like the competition.
Depending on what you mean by "physics engineer", there's a good chance he/she will use one as a data source, albeit usually a fairly simple one. Accessing a database table is easier than parsing a flat file, generally speaking. A graphics engineer either falls into that "mostly down at the kernel level" category or will end up reading model data blobs from a database for some project eventually. And a web dev doing the JavaScript side needs to at least understand enough about what's happening under the hood to be able to ask good questions and understand why only certain things are possible. Mind you, these are very basic uses of a database, and require only the most lightweight understanding of how things work.
Nobody who isn't deploying servers needs to understand data replication. That's a tiny niche area in the database world. Similarly, most people don't need to know concurrency details. That said, I think everyone should at least understand the basic concepts—tables, primary keys, normalization, etc.—and the easiest way to learn those concepts is by interacting with an actual database.
IMO, a function should be as long as it needs to be, and no shorter or longer. If the most easily understood way to express a concept is as a 5,000 line function, then you should write a 5,000 line function. Splitting up a function based on some arbitrary length limitation can only lead to less readable code.
For example, my record is almost 5,500 lines. The entire function is basically a giant switch statement in a parser (post-tokenization). The only way you could make that function significantly shorter would be to shove each case into a function, and all that would do is make it harder to follow the program flow through the function for no good reason. At any given moment, you're still going to be staring at exactly one of those cases per token (plus a little code on either end), so having each case in a separate function just adds execution overhead without improving readability, and it makes debugging harder because you now have to pass piles of flags around everywhere instead of just using a local variable.
One of the data structures for the function in question is almost 1200 lines long by itself (including anywhere from two to fifteen lines of explanation per field, because I wanted to make sure this code is actually maintainable). By itself, the initializer for that data structure cannot meet your "fits on one screen" rule, even with most of the fields auto-initialized to empty. And there's no good way to shrink that data structure. It is a state object for a very complex state machine. The code to interpret the end state is over a thousand lines of code by itself.
In short, those sorts of rules simply don't make sense once the problem you're trying to solve becomes sufficiently complex. They're useful as guidelines for people who don't know how to write code yet—to help them avoid making obscenely complex functions when the functionality is reasonably separable into smaller, interestingly reusable components, to keep themselves from shooting themselves in the foot by repeating code where they should call a shared function, and so on. However, IMO, if you're still thinking about rules by a few years out of school, they're probably doing you more harm than good, causing you to write code with unnecessary layers of abstraction for the sake of abstraction.
When it was part of our CS required curriculum, I suspected I would never use it, but it turns out that the vast majority of projects I've been involved with have used databases in some way, and one of them even involved some pretty serious database query optimization. As far as I can tell, unless you pretty much code exclusively down at the kernel level, you're going to eventually be asked to work on some project involving databases. They're the glue that holds technology together. Outside of a handful of niche fields, I'd be surprised if any programmer managed to go more than five years out of school without having to work with one.
Also, once you understand databases conceptually, everything starts to look like a special case of a database. This is a good thing. C data structures? Table records. Pointers? Relations. And so on. It ends up helping you understand complex problems even if you're one of those rare people who never ends up touching an actual database.
No, no, it's a Pluto week, which is about a month and a half in Earth time. :-D
Actually, it is. Electronic gauges don't typically stick. Don't get me wrong, a mechanical backup should be mandatory so that an electronics failure doesn't result in being unable to get readings at a critical moment, but using them as the primary readout mechanism is a recipe for disaster.