IIRC copyright law has been modified to allow temporarily copying a program into RAM in order to run it, so a EULA packaged with a product you've already purchased is probably unenforceable (partly because in practice you can't get a refund when the terms are unacceptable). A EULA that actually had to be signed as a condition of purchase ought to be valid.
Being just a cross between work-for-hire and shareware, this idea's been around for a while. I've had it for a few years now, though I haven't had the time and gumption to put it into practice. In short, I'm concerned that the community won't tolerate temporary hoarding, in fairness I may have to allow totally proprietary derived works, and the psychology it'll take to reach the ransom isn't clear.
The story should have included a warning, at least. Anyone who sees it and decides it's now a good idea to buy a Radeon is in for a nasty surprise. Since Linux' claim to fame is being free, describing this as a driver "for Linux" is awfully misleading (even if it does seem to run on recent versions).
The card can already demux MTS audio from NTSC. Compared to a pair of signal amps, another jack in the slot cover, a cable, and tech support for users who can't figure out where the cable goes, it's gotta be cheaper to add a pair of audio ADCs and read samples through the driver.
Did anyone else think it was just a bit suspicious that the Seattle Center/Westlake monorail (which had been running flawlessly for years) broke down twice in a row just a couple of months before the citywide vote?
We live up by Northgate, because that's where bus commuting is at least tolerable yet we can afford a decent apartment. In my ten-year career I've worked at seven companies in ten different offices, ranging from Fremont to the eastside to Rainier Beach. A manager at one company thought he was being clever by buying a house on Mercer Island just up the hill from the office--so they promptly moved the dev team to Bellevue, then Seattle, and now Issaquah.
Living where you work is a nice theory, but since even viable employers can't offer job security and still aren't comfortable with telecommuting, unless you're going to break your lease or sell your home every few quarters it's not going to happen except by chance.
Agility also depends on how adaptable the project's current state is, not just team mindsets. If you do a grand design up front and don't maintain comprehensive unit tests, major changes are going to involve huge risk and lost work.
Wagner appears to live in the US, which is hardly known for having an infallible legal system in which nuisance and SLAPP lawsuits cost innocent victims nothing.
The abstraction is a reliable byte stream, which of course isn't really possible due to phenomena that can only be affected by interfaces beneath TCP. A leak that's documented is still a leak.
A whine? I took it as a warning: even if you don't use the layers underneath your favorite abstraction, learning how they work is not optional, and people who haven't are not going to be able to solve all their own problems.
As he argues, "paradoxically [...] becoming a proficient programmer is getting harder and harder," though posing as one and being able to get some stuff to vaguely work is getting easier--the frequency at which proficient programmers are needed is going down.
edge conditions in which your data is recieved but you never receive the ACK(nowledge) and therefore assume that the messasge was lost.
This is called the Two Generals Problem (they only win if they both attack, but they can't be sure the last messenger made it past the enemy). Sadly, there's a proof that it can't be solved.
The less skilled of a pair should usually be driving. That way they have to understand their partner's suggestions (instead of letting their eyes glaze over while watching them appear) and they'll become more skilled. Look at it as a training cost. If they can't or don't want to learn and improve, software is not the field for them.
There have been many broken Linux releases (remember the 2.4 VM mess? IDE in early 2.5?), and that's the way it's supposed to be--the point is to get them into people's hands and find that out. No amount of software design can prove that all commodity hardware actually behaves the way you thought it does.
IMHO Linux isn't much like an XP project. There's no comprehensive unit test suite--the Linux Test Project isn't integrated and mostly goes after system loads, and patches without test cases are continually being applied. Refactoring in the kernel sounds pretty hard, so it happens seldom and reluctantly. Not all contributors are rigorous; quality is only high because Linus can reject any patch that doesn't look sound. Ownership of many subsystems seems stronger than XP recommends. But most every kernel hacker is also a serious kernel user, so I'd say the onsite customer practice is in good use.
The simplest thing that could possibly work (don't design more than you already need, and be ready to evolve it) is a tenet of XP. AbstractFactoryContainerXYZYourMom instead of a getter sounds like architecture astronaut-grade overgeneralized design in advance (or slavishly following design patterns instead of adapting them to your needs). Pair programming doesn't guarantee that what you were doing was XP.
The elegant API is read/write with OS-provided buffers. This can be zero-copy, asynchronous, transactional, admit pipes and network associations as well as random-access files, work without vast unused address space (and wasted I/O and physical RAM and TLB contention from trying to guess about readahead and writeback), and make performance much more predictable (you never have to guess which pointer uses will block you and start swapping unless your physical RAM is inadequate for your software).
mmap() is simple when it works, but the things it can't express show it's a poor fit for the problem space.
Also allowing plugins to communicate with each other and the DOM of the embedding document (and any scripts it may contain). Pushing URLs to viewers alongside a stream is a common example.
IANAL but I'm not this poorly informed. Copyrights and patents can indeed be enforced selectively. Generally estoppel and laches prevent you from suing over infringements long past, but as soon as you tell an infringer to stop, they're liable for damages over any infringement from that point forward. (Before the Berne Convention you could lose a copyright by acquiescing to publicatation without a copyright notice, but that was decades ago.)
Trademarks, however, can be lost by nonenforcement. I'm not sure why; maybe because they can be renewed forever (though it looks like copyrights will be too) or were considered a larger imposition on the rest of the market.
Reverse engineering isn't affected by copyright unless you create a derived work in the process (rather than learning the algorithm, which can't be copyrighted, and then implementing it yourself). The (hopefully unconstitutional) DMCA prohibits offering circumvention tools, but in that case it doesn't matter whether you created the tool by reverse engineering.
Driver's licenses are only required to use public roads. If you don't own your vehicle, you may need to agree to insure it, which may require being licensed, but I can't think of a case where the government has the authority to forbid you from owning a car.
Opportunities to take a driving test are available widely and without discrimination. Certain cities and states are known for mandating firearm training and then making it unavailable to ordinary citizens--in one case last decade (New York?), there was space for some twenty students per year, and oddly enough every student was a bodyguard for a wealthy politician or executive.
Driving is so nearly universal in the US that a list of licensed drivers wouldn't be a useful tool of tyranny. Gun registration is typically a prelude to confiscation (care to guess why Jewish Germans were helpless when the Nazis finally came to imprison them?)
Infringing the right to drive isn't specifically forbidden by the US Constitution, so passing such laws can be within federal or state governments' authority.
That's merely comfort. Freedom is about what you can do (legally), not what can or can't be done to you.
I think you've drastically overstated the rate of accidents involving firearms, but either way the idea of a society remaining free under a government that cannot be overthrown is sheer fantasy.
HTTP is only so-so. A good RPC protocol should label requests and allow servers to execute them and send responses out of order (without an extra connection per logical thread) as well as negotiating the best mutually-supported encoding (US-ASCII headers are almost as ludicrously expensive as XML, and HTTP doesn't even allow compression there), and a UDP mapping (something like SIP) would really help with round-trip latency for isolated requests.
AFAICT, SOAP/1.2 will drop the SOAPAction header in favor of an optionalaction parameter in the media type--not that it wouldn't be easy to spoof and hard for a proxy to find (everything's variable-length in HTTP headers), even if it were mandatory.
Slashdot Mirror
Win95 isn't free. Its source will probably never be published, regardless of if and when it paid for itself.
Ransom refers to releasing from captivity. If it didn't already exist, you'd really be paying them to create it, not just to license it.
IIRC copyright law has been modified to allow temporarily copying a program into RAM in order to run it, so a EULA packaged with a product you've already purchased is probably unenforceable (partly because in practice you can't get a refund when the terms are unacceptable). A EULA that actually had to be signed as a condition of purchase ought to be valid.
Being just a cross between work-for-hire and shareware, this idea's been around for a while. I've had it for a few years now, though I haven't had the time and gumption to put it into practice. In short, I'm concerned that the community won't tolerate temporary hoarding, in fairness I may have to allow totally proprietary derived works, and the psychology it'll take to reach the ransom isn't clear.
Yeah, ISO/ANSI didn't define it until C99. (In C++ you should have been using stringstreams anyway.)
The story should have included a warning, at least. Anyone who sees it and decides it's now a good idea to buy a Radeon is in for a nasty surprise. Since Linux' claim to fame is being free, describing this as a driver "for Linux" is awfully misleading (even if it does seem to run on recent versions).
The card can already demux MTS audio from NTSC. Compared to a pair of signal amps, another jack in the slot cover, a cable, and tech support for users who can't figure out where the cable goes, it's gotta be cheaper to add a pair of audio ADCs and read samples through the driver.
Did anyone else think it was just a bit suspicious that the Seattle Center/Westlake monorail (which had been running flawlessly for years) broke down twice in a row just a couple of months before the citywide vote?
We live up by Northgate, because that's where bus commuting is at least tolerable yet we can afford a decent apartment. In my ten-year career I've worked at seven companies in ten different offices, ranging from Fremont to the eastside to Rainier Beach. A manager at one company thought he was being clever by buying a house on Mercer Island just up the hill from the office--so they promptly moved the dev team to Bellevue, then Seattle, and now Issaquah.
Living where you work is a nice theory, but since even viable employers can't offer job security and still aren't comfortable with telecommuting, unless you're going to break your lease or sell your home every few quarters it's not going to happen except by chance.
Agility also depends on how adaptable the project's current state is, not just team mindsets. If you do a grand design up front and don't maintain comprehensive unit tests, major changes are going to involve huge risk and lost work.
Wagner appears to live in the US, which is hardly known for having an infallible legal system in which nuisance and SLAPP lawsuits cost innocent victims nothing.
The abstraction is a reliable byte stream, which of course isn't really possible due to phenomena that can only be affected by interfaces beneath TCP. A leak that's documented is still a leak.
As he argues, "paradoxically [...] becoming a proficient programmer is getting harder and harder," though posing as one and being able to get some stuff to vaguely work is getting easier--the frequency at which proficient programmers are needed is going down.
This is called the Two Generals Problem (they only win if they both attack, but they can't be sure the last messenger made it past the enemy). Sadly, there's a proof that it can't be solved.
TCP SACK (which suggests a resend of the blocks between the acknowledged ones) is becoming common; Linux 2.1.100 and Win98 both had it.
The less skilled of a pair should usually be driving. That way they have to understand their partner's suggestions (instead of letting their eyes glaze over while watching them appear) and they'll become more skilled. Look at it as a training cost. If they can't or don't want to learn and improve, software is not the field for them.
There have been many broken Linux releases (remember the 2.4 VM mess? IDE in early 2.5?), and that's the way it's supposed to be--the point is to get them into people's hands and find that out. No amount of software design can prove that all commodity hardware actually behaves the way you thought it does.
IMHO Linux isn't much like an XP project. There's no comprehensive unit test suite--the Linux Test Project isn't integrated and mostly goes after system loads, and patches without test cases are continually being applied. Refactoring in the kernel sounds pretty hard, so it happens seldom and reluctantly. Not all contributors are rigorous; quality is only high because Linus can reject any patch that doesn't look sound. Ownership of many subsystems seems stronger than XP recommends. But most every kernel hacker is also a serious kernel user, so I'd say the onsite customer practice is in good use.
(BTW, Waterfall Model was misspelled.)
The simplest thing that could possibly work (don't design more than you already need, and be ready to evolve it) is a tenet of XP. AbstractFactoryContainerXYZYourMom instead of a getter sounds like architecture astronaut-grade overgeneralized design in advance (or slavishly following design patterns instead of adapting them to your needs). Pair programming doesn't guarantee that what you were doing was XP.
mmap() is simple when it works, but the things it can't express show it's a poor fit for the problem space.
Also allowing plugins to communicate with each other and the DOM of the embedding document (and any scripts it may contain). Pushing URLs to viewers alongside a stream is a common example.
IANAL but I'm not this poorly informed. Copyrights and patents can indeed be enforced selectively. Generally estoppel and laches prevent you from suing over infringements long past, but as soon as you tell an infringer to stop, they're liable for damages over any infringement from that point forward. (Before the Berne Convention you could lose a copyright by acquiescing to publicatation without a copyright notice, but that was decades ago.)
Trademarks, however, can be lost by nonenforcement. I'm not sure why; maybe because they can be renewed forever (though it looks like copyrights will be too) or were considered a larger imposition on the rest of the market.
Reverse engineering isn't affected by copyright unless you create a derived work in the process (rather than learning the algorithm, which can't be copyrighted, and then implementing it yourself). The (hopefully unconstitutional) DMCA prohibits offering circumvention tools, but in that case it doesn't matter whether you created the tool by reverse engineering.
I think you've drastically overstated the rate of accidents involving firearms, but either way the idea of a society remaining free under a government that cannot be overthrown is sheer fantasy.
When hate speech is uttered openly, it can be debunked and ridiculed. Banning it only gives it unwarranted credibility.
False dichotomy. Life has no value without freedom.
AFAICT, SOAP/1.2 will drop the SOAPAction header in favor of an optional action parameter in the media type--not that it wouldn't be easy to spoof and hard for a proxy to find (everything's variable-length in HTTP headers), even if it were mandatory.