So individual apps had to be aware of the individual drivers.
For some drivers, yes. Drivers that defined block devices just showed up as a drive letter and were available to any program without any device-specific code needed in the user app itself, although there occasionally was a system EXE that needed to be run as well to provide the functionality. Examples include CD-ROM support under DOS (with a device-specific driver + MSCDEX.EXE to read the filesystem on the drive) and RAM drive support (RAMDRIVE.SYS).
Or, in the real world, do X anyway as secretive as possible and hope the courts don't order them to stop.
The courts don't mean much to these people - the FISA court's own statements about being misled by the NSA proves that. The only thing within the law guaranteed to stop them is to start jailing those responsible or cutting off their funding.
I think it needs to come directly out of the affected officers' pockets, in the form of an individual professional liability insurance policy similar to what doctors carry. Make that coverage a condition for employment in a law enforcement capacity. If the cop does his job right, his premiums stay low. If he screws up too much, his premiums will get so high that he can't continue to work in that field, or won't be able to find an insurer to cover him. No insurance, no job. A side benefit is that as the percentage of claims that get paid out rises, the cost is spread over the entire profession, which gives cops a financial incentive to keep their own in line.
I meant effective measures, as in holding those in law enforcement personally accountable. Not their departments, not the city, but personally. This business of giving police officers, district attorneys, and judges near-absolute immunity for their actions needs to be looked at a lot more closely.
Complaining about actual or alleged abuses by this or that police officer or department doesn't change the role of the police in the criminal justice system and their function of law enforcement.
It doesn't change the intended role. In reality, that role is often not adhered to, and when it's not, there is usually precious little the populace can do about it while remaining within the confines of the law.
They're designed to allow HR and recruiters to select the specific set of buzzwords they're looking for but have no understanding of, all while doing the minimum amount of work and the least amount of understanding.
The bolded statement sums it up. These application systems are intended to offload as much data entry work onto the candidate as possible. From the company's perspective, why should they pay HR to do data entry when they can get the candidates to do it for free?
If you do anything across state lines it falls to the Feds which are 1 party.
Courts have gone both ways about that. In Lane vs. CBS Broadcasting, the federal court held that in the absence of explicit stated intent to the contrary, complete federal preemption only applied in cases in which state law was less restrictive, and otherwise the state's law applied. In my state (an all-party state), I don't think your statement is something I'd want to bet a third-degree felony conviction on.
I find web development rather simple in comparison to trying to write a basic thread manager for a PIC18F uC, not saying you're wrong, just different views.
I should probably elaborate on my statement - I find web development more challenging because of the variety of stuff beyond my control that I have to account for. Different OSs, different browsers, different interpretations of the HTML/CSS specs, etc., whereas in the embedded world, you generally have pretty tight control over the platform you're working with, and you can say with some degree of certainty that the processor is going to take X number of nanoseconds to run a particular block of code or respond to an interrupt. If I'm writing something to run on a microcontroller, almost any problem I have with the code not running properly is going to be the result of a something that I've screwed up myself. While I can certainly screw up in a higher level environment, there are constantly issues to deal with involving inconsistent or undocumented behavior of the platform, or component bugs not of my own doing that still have to be identified and worked around. You don't get stalled by unexpected garbage collection when working on a PIC in assembly, and you don't have to be familiar with 18 zillion frameworks just to get text out to an LCD.
I will definitely agree that embedded work demands a much more complete understanding of how the machine actually works and the ability to decompose a solution into much more detail, but it's much less fatiguing for me because there's a lot less crap getting in the way of getting stuff working. It's also a lot more fun.:-)
A real programmer interfaces at the hardware level and tells a computer how to do it's job without having to use bulky objects, interfaces and abstraction.
Ah, a variation on the "No True Scotsman" fallacy. A "real" programmer is familiar with a wide set of tools and the knowledge when to use each. There are times when that tool set includes the ability to read schematics and an oscilloscope or DMM to verify proper operation of hand-written assembly, and there are times when huge enterprise projects require tons of abstraction in a high-level language in order to keep the complexity manageable.
Frankly, I find web development a hell of a lot more challenging than embedded work.
"by zapping with electricity water bubbling through a matrix of iron oxide"
To me, the original statement implies there's a special kind of water called "electricity water", while the paraphrased version offered is merely awkward. I think a better way to phrase it would have been "by applying electricity to water bubbling through a matrix of iron oxide". [shrug]
but nothing can convince a collection agency that they were sold bad debt.
Having to explain to the judge why they're collecting when you can prove you paid it often works, and can put *their* money in your pocket to boot. Small claims court is great for this, especially when they don't bother showing up and you get a default judgment.
I said no problems, just give me a copy of the invoice and we'll pay up.
They said. Can't do that.
The proper response: "If you can't validate the debt, you can't legally attempt to collect it, and if you continue to do so I'll sue you for violating the applicable sections of the federal Fair Debt Collection Practices Act, in addition to whatever state laws apply. You'll be receiving a letter via certified mail saying essentially the same thing once you give me your agency's name and address."
To cut a long story short, the phone company sells anything past due date to a collection agency BUT doesn't bother to give them the supporting documentation.
How retarded is that!
It's stupid of any collection agency to fail to get the necessary documentation to prove a debt is valid, but it works very much in favor of the supposed debtor.
No, the traceroute wouldn't show the hops between your PC and the VPN server, so that part of path could not be compared.
This is true as long as the VPN link is up. If it's down, then it's trivial to do a traceroute between yourself and the VPN server to fill in the missing hops.
I don't care how big they get because they can't form the same kind of monopoly.
And this is why content providers and ISPs should be separate. This is only an issue for cable companies because they provide both bandwidth and content, and Netflix threatens their content offerings because it provides a service that people actually *want* at a reasonable price.
Can anyone recommend a SOHO-level router that properly supports IPv6? Right now I've got my desktop on a Teredo (okay, stop laughing) tunnel set up to a server I have colo'd which in turn has a real/64. It works pretty well, but it was a pain to set up and counts against my colo bandwidth, and of course adds a bit of latency. Router support for IPv6 may be moot since I don't even know for sure that AT&T has IPv6 rolled out here anyway.
18,446,744,073,709,551,616, or 18 quintillion, or 18 million trillion, minus a couple for netblock addresses. "Practically unlimited" is a good term here.:-)
Your argument boils down to "Engineering is hard".
Not at all. The main point of my argument is that the idea that requirements are free to be changed, regardless of scope, is resulting in implementation being far more expensive than it needs to be, and IMO this isn't a good engineering practice. How many development shops take the customer aside after a project is finished, show him the dollar amounts for all the change orders, and point out that having had the requirements more in order beforehand might have ended up only costing him only half of what it actually did? "But you saw new stuff working every two weeks, even if it wasn't what you really needed!"
Requirements analysis is (or should be) just as much part of any engineering discipline as construction. Some degree of change is inevitable, but we shouldn't be in the situation where we build an airplane with four wings before determining two would have been sufficient.
Ah, okay - yes, you're absolutely right that the Windows environment itself doesn't come with what you need to be productive as a programmer, and you do have to know what you need beforehand.
OK, maybe that last one''s a stretch. Nobody bothers to document "simple" programs, since we all know the code IS the documentation and any good programmer can work out what is going on (are they still teaching that garbage?)
Not just teaching it, *practicing* it. My boss is a hardcore Agile fan, and his official stance is "out of date documentation is worse than no documentation, so don't spend any time documenting anything, and if you can't figure out why this 12-year-old code is doing something, find someone in the group that does". Nice, except none of the guys that actually wrote that cruft are still there, and reading code doesn't necessarily provide any insights as to the higher-level theory of operation when multiple modules work together. Then on top of that, he says "I don't want to see any research tasks in this sprint". So what, I'm supposed to know how this works by osmosis?
Slashdot Mirror
That number is just what the film distributor's marketing department *claims* they lost.
Never trust what anyone involved with the movie industry says about profits and losses. I don't necessarily disagree with this individual facing some kind of punishment, as I feel limited and reasonable copyright legislation helps more than it hurts, but I do agree that one needs to take the losses stated with a very large grain of salt.
White-collar criminals usually have much more to lose by being imprisoned as well.
So individual apps had to be aware of the individual drivers.
For some drivers, yes. Drivers that defined block devices just showed up as a drive letter and were available to any program without any device-specific code needed in the user app itself, although there occasionally was a system EXE that needed to be run as well to provide the functionality. Examples include CD-ROM support under DOS (with a device-specific driver + MSCDEX.EXE to read the filesystem on the drive) and RAM drive support (RAMDRIVE.SYS).
Or, in the real world, do X anyway as secretive as possible and hope the courts don't order them to stop.
The courts don't mean much to these people - the FISA court's own statements about being misled by the NSA proves that. The only thing within the law guaranteed to stop them is to start jailing those responsible or cutting off their funding.
I think it needs to come directly out of the affected officers' pockets, in the form of an individual professional liability insurance policy similar to what doctors carry. Make that coverage a condition for employment in a law enforcement capacity. If the cop does his job right, his premiums stay low. If he screws up too much, his premiums will get so high that he can't continue to work in that field, or won't be able to find an insurer to cover him. No insurance, no job. A side benefit is that as the percentage of claims that get paid out rises, the cost is spread over the entire profession, which gives cops a financial incentive to keep their own in line.
I meant effective measures, as in holding those in law enforcement personally accountable. Not their departments, not the city, but personally. This business of giving police officers, district attorneys, and judges near-absolute immunity for their actions needs to be looked at a lot more closely.
Complaining about actual or alleged abuses by this or that police officer or department doesn't change the role of the police in the criminal justice system and their function of law enforcement.
It doesn't change the intended role. In reality, that role is often not adhered to, and when it's not, there is usually precious little the populace can do about it while remaining within the confines of the law.
They're designed to allow HR and recruiters to select the specific set of buzzwords they're looking for but have no understanding of, all while doing the minimum amount of work and the least amount of understanding.
The bolded statement sums it up. These application systems are intended to offload as much data entry work onto the candidate as possible. From the company's perspective, why should they pay HR to do data entry when they can get the candidates to do it for free?
If you do anything across state lines it falls to the Feds which are 1 party.
Courts have gone both ways about that. In Lane vs. CBS Broadcasting, the federal court held that in the absence of explicit stated intent to the contrary, complete federal preemption only applied in cases in which state law was less restrictive, and otherwise the state's law applied. In my state (an all-party state), I don't think your statement is something I'd want to bet a third-degree felony conviction on.
I find web development rather simple in comparison to trying to write a basic thread manager for a PIC18F uC, not saying you're wrong, just different views.
:-)
I should probably elaborate on my statement - I find web development more challenging because of the variety of stuff beyond my control that I have to account for. Different OSs, different browsers, different interpretations of the HTML/CSS specs, etc., whereas in the embedded world, you generally have pretty tight control over the platform you're working with, and you can say with some degree of certainty that the processor is going to take X number of nanoseconds to run a particular block of code or respond to an interrupt. If I'm writing something to run on a microcontroller, almost any problem I have with the code not running properly is going to be the result of a something that I've screwed up myself. While I can certainly screw up in a higher level environment, there are constantly issues to deal with involving inconsistent or undocumented behavior of the platform, or component bugs not of my own doing that still have to be identified and worked around. You don't get stalled by unexpected garbage collection when working on a PIC in assembly, and you don't have to be familiar with 18 zillion frameworks just to get text out to an LCD.
I will definitely agree that embedded work demands a much more complete understanding of how the machine actually works and the ability to decompose a solution into much more detail, but it's much less fatiguing for me because there's a lot less crap getting in the way of getting stuff working. It's also a lot more fun.
A real programmer interfaces at the hardware level and tells a computer how to do it's job without having to use bulky objects, interfaces and abstraction.
Ah, a variation on the "No True Scotsman" fallacy. A "real" programmer is familiar with a wide set of tools and the knowledge when to use each. There are times when that tool set includes the ability to read schematics and an oscilloscope or DMM to verify proper operation of hand-written assembly, and there are times when huge enterprise projects require tons of abstraction in a high-level language in order to keep the complexity manageable.
Frankly, I find web development a hell of a lot more challenging than embedded work.
"by zapping with electricity water bubbling through a matrix of iron oxide"
To me, the original statement implies there's a special kind of water called "electricity water", while the paraphrased version offered is merely awkward. I think a better way to phrase it would have been "by applying electricity to water bubbling through a matrix of iron oxide". [shrug]
What the car needs to do is find the nearest exit, pull off, and then pull onto the shoulder.
Then once stopped, automatically deploy the artificial arm and slap the driver firmly about the head and shoulders.
People are so afraid of a credit rating problem these days that they will often pay off a "bad debt" that is fraudulent to get their score "fixed".
And this is sad, because they're not aware that there are some relatively strong laws that protect them in regards to debt collectors.
but nothing can convince a collection agency that they were sold bad debt.
Having to explain to the judge why they're collecting when you can prove you paid it often works, and can put *their* money in your pocket to boot. Small claims court is great for this, especially when they don't bother showing up and you get a default judgment.
I said no problems, just give me a copy of the invoice and we'll pay up. They said. Can't do that.
The proper response: "If you can't validate the debt, you can't legally attempt to collect it, and if you continue to do so I'll sue you for violating the applicable sections of the federal Fair Debt Collection Practices Act, in addition to whatever state laws apply. You'll be receiving a letter via certified mail saying essentially the same thing once you give me your agency's name and address."
To cut a long story short, the phone company sells anything past due date to a collection agency BUT doesn't bother to give them the supporting documentation.
How retarded is that!
It's stupid of any collection agency to fail to get the necessary documentation to prove a debt is valid, but it works very much in favor of the supposed debtor.
It'll be recycled, but what they'll get for the shavings will be a lot less than the equivalent weight of a fresh block.
No, the traceroute wouldn't show the hops between your PC and the VPN server, so that part of path could not be compared.
This is true as long as the VPN link is up. If it's down, then it's trivial to do a traceroute between yourself and the VPN server to fill in the missing hops.
I don't care how big they get because they can't form the same kind of monopoly.
And this is why content providers and ISPs should be separate. This is only an issue for cable companies because they provide both bandwidth and content, and Netflix threatens their content offerings because it provides a service that people actually *want* at a reasonable price.
Can anyone recommend a SOHO-level router that properly supports IPv6? Right now I've got my desktop on a Teredo (okay, stop laughing) tunnel set up to a server I have colo'd which in turn has a real /64. It works pretty well, but it was a pain to set up and counts against my colo bandwidth, and of course adds a bit of latency. Router support for IPv6 may be moot since I don't even know for sure that AT&T has IPv6 rolled out here anyway.
With all the IPV6 address space available, why not give out a static IPV6 prefix, but no, they want to change it frequently.
Because they don't want you running servers with a static IP? Can't have that now, can we?
18,446,744,073,709,551,616, or 18 quintillion, or 18 million trillion, minus a couple for netblock addresses. "Practically unlimited" is a good term here. :-)
Your argument boils down to "Engineering is hard".
Not at all. The main point of my argument is that the idea that requirements are free to be changed, regardless of scope, is resulting in implementation being far more expensive than it needs to be, and IMO this isn't a good engineering practice. How many development shops take the customer aside after a project is finished, show him the dollar amounts for all the change orders, and point out that having had the requirements more in order beforehand might have ended up only costing him only half of what it actually did? "But you saw new stuff working every two weeks, even if it wasn't what you really needed!"
Requirements analysis is (or should be) just as much part of any engineering discipline as construction. Some degree of change is inevitable, but we shouldn't be in the situation where we build an airplane with four wings before determining two would have been sufficient.
Ah, okay - yes, you're absolutely right that the Windows environment itself doesn't come with what you need to be productive as a programmer, and you do have to know what you need beforehand.
OK, maybe that last one''s a stretch. Nobody bothers to document "simple" programs, since we all know the code IS the documentation and any good programmer can work out what is going on (are they still teaching that garbage?)
Not just teaching it, *practicing* it. My boss is a hardcore Agile fan, and his official stance is "out of date documentation is worse than no documentation, so don't spend any time documenting anything, and if you can't figure out why this 12-year-old code is doing something, find someone in the group that does". Nice, except none of the guys that actually wrote that cruft are still there, and reading code doesn't necessarily provide any insights as to the higher-level theory of operation when multiple modules work together. Then on top of that, he says "I don't want to see any research tasks in this sprint". So what, I'm supposed to know how this works by osmosis?