I'm familiar of this use of jargon, although not of the intent. To my mind, this has always seemed fairly silly. C defines quite a few high-level constructs which you don't generally see in assembly code. Loops, simple subroutines, pretty much all control structures really. Add to that a typing system that goes well beyond that of the hardware, support for user-defined complex data types, and a robust user library. Yes, these are easily implementable in various assembly languages, but to say they are part of the language is rarely, if ever, true.
My interpretation of the C as assembly code jargon has always been that it combines the low-level power of assembly code with the features of a high-level language.
This did return more results for some search terms than google. Not many of the extras seemed all that useful, though. The signal to noise ratio seems a bit lower.
The ordering of pages seems less helpful. In many cases, the page I'm looking for is farther down the page.
The sponsored links and advertising are way more noticeable, and get in the way of the search results, although they're probably easy enough to ignore.
Google seems to be better at rating by search term proximity, under the useful assumption that if the search terms occur close to each other, it is less likely to be a random hit. One irritation with AllTheWeb is that for many results, it doesn't show you the context of the search terms in the summary.
Obviously AllTheWeb lacks the excellent USENET archive. The video and MP3 search festures might be pretty useful, I haven't had a chance to try them.
I realize I'm coming across as entirely pro-Google, but these are the only observations I have right now. I'll give AllTheWeb a chance, and let internet darwinism settle the issue.
The C programming language is best described as a hardware-independent assembler language.
Ugh. Sorry, but this one is a bit hard to swallow. Bytecode was not a new concept when java hit the schene, but that is no reason confuse portable source from portable binaries. Or to start making high- (or mid-) level languages equivalent to assembly code.
I think Joel starts out with a fairly good idea, which applies well to companies like IBM and HP, and tries to over-apply it. Why be compelled to include the Netscape example, when even he admits it doesn't work? Despite this, I think his observations are fairly insightful.
I didn't suspect this would need clarification, but the point is that if you share network drives with people who have bad email skills, or with people who share systems with them, you can be infected. As an extra bonus, places that let their web designers mount the document tree as a network drive have a nice chance of spreading the virus through downloads, if the serve up any exe's.
Plus, the point isn't if the user can do anything about holes in IE. They still can present a danger that email skills will not protect you from.
Reading press releases from Warner is like watching professional tennis. They seem to jump over the dividing line in consumer rights debates several times a minute.
Boing! Buy Netscape, happy open sourcy browser!
Boing! Build new AOL service around evil monopolistic browser!
Boing! Buy winamp, make it free!
Boing! All digital devices must have approved copy protection! arrr!
Boing! Rebuild AOL around Mozilla!
Boing! Skipping commercials is theft!
Boing! Macrovision is evil!
Does anyone else get the idea that the merger left these guys with permanant split-brain syndrome?
Unfortunatley, this is not entirely true. Quite a few of these viruses are happy to infect non email files once they get on a network via the email vector. We haven't seen many where I work, but we have seen a few that will infect various system files. Then, when a user logs into that system, the virus infected system will gleefully infect any exe's on the network that that user has write access to. Log into a machine like this as a domain administrator, and the chances of it getting to every machine on the network without them opening any email message is quite good.
Some of them will replace.jpg and mp3 files with dummy executables that Explorer will foolishly make look like the original files. So common MP3 shares and such make a pretty good vector for crossing the network, as well.
competitively priced notebooks (not to mention sexy)
Brrr... I'm sorry, but I think that Apple, with its "sexy" machines is a major threat to human life on this planet. Apple wants us to redirect all our sexual energy into playing with computers, thus trimming the population growth rate, and making us weak. That way, we will be vulnerable when their teal-plastic-bubble robots move in to take control of the planet.
Sure, it would be a benevolent dictatorship, with easy-to-use interfaces and open standards, but consider the horror when a person's largest muscle is his right index finger, from clicking that one button thousands of times a minute.
Seriously, though, this is not a new tactic from Apple. The lack of a version of Final Cut Pro for Intel platforms has seriously annoyed me for a while. I can see this as a viable way to push their hardware, but I'm not sure they end up making more money by doing so. Limiting one of the best video editing packages to ~10% of the possible market is missing a big oppurtunity.
When it comes down to it, I think Apple's software is what distinguishes it. The interesting form factors they put through are neat, but could be done as well with Intel hardware. Really Apple hardware doesn't do anything Intel hardware can't, except run MacOS. They would sell much more hardware, I think, if it was x86 based. But then they'd have nothing to push their operating system.
So in the end, I have to wonder, is Apple using its software to push the hardware, or its hardware to push the OS platform.
I'm sure I'll get flamed to hell and back for this one, but here goes:
We want ICANN to act like a decent international regulatory body. Having it act no more evil than ANSI of IEEE would be nice. Unfortunately, ICANN has a bit more going for it, mainly:
It has the power to force people to follow its will. Unlike most standards organizations, it doesn't have to be democratic to elicit buy-n.
It's regulatory consessions are worth a great deal of money to some people.
So, to make sure it acts like a public group and not like a business, we feel the need to place some sort of authoritarian control over it. Since its domain is the world, however, the US government makes little sense for this. How about the UN?
Now I know that many see the UN as either useless or evil, but in certain cases (the World Health Organization, UNICEF,...) it can do a lot of good while keeping things under world-wide semi-democratic oversight.
One of the biggest problems can be lack of compliance to actual or de facto API standards. An OS that doesn't track community standards closely, like my pet peeve, HP-UX, can make a lot of work. Many times, we have been wanting to go forward with a new architecture for some aspect of our systems, only to be held up for quite some time because the software would not compile for HP-UX. The number of open source projects we've needed to port to make them work as well on HP as on Solaris or Linux is considerable. So, keep in mind that sometimes a non-feature like the system library environment can make a lot of difference in running an OS.
I made reference to the difficulty of bootstrapping hydrogen as a fuel source (i.e. creating it without another, equally good and clean source of power). As for pollution, the plants aren't going to remove the carbon monoxide from the air, which was the main point I hoped to make. I personally think Biodiesel is a gret fuel, but one also must acknowledge that it burns dirtier than a process that produces only water vapor. Now efficient large scale biodiesel generators fueling hydrogen production, that might be a beautiful thing. Keep all the organic molecule burning in centralized places where the economy of scale can reduce unburnt fuel, and where high quality air cleaners can be afforded. The best of both worlds.
Firstly, I think this trend is a very bad one, but not a sustainable one. It think the medium term effects of this regulatory change will be obvious and will make even fairly jaded political entities scramble to change it back. Firstly, these regulatory changes stand to make most of the providers without last mile networks either go out of business or cut back considerably, something that will be very visible in the current economy. Secondly, a lot of the people who are using broadband now, second-tier adopters, will be pretty damned disillusioned if the providers start screening content. Even if they don't give up on broadband, they'll probably stop evangelizing their mainstream, less geeky friends. I think that sort of thing would slow adoption to a crawl, which the opposite of what the FCC thinks its doing.
Mainly, I think its important to remember that this kind of policy change can be reversed just about instantly. I think the providers know this too, and will not bet the farm that abusing the new state of affairs will not cause such a reversal from future FCC appointees.. In many ways, we'd be much worse off if all of these changes had come through Congress.
Secondly, and more contrarily, I think its rather strange to classify a market media monopoly as a First Amendment violation. The First Amendment has nothing to do with publication. It guarantees that the government will not restrict your voice. It does not guarantee that the government will regulate the market to make people publish that voice. Media monopolies are wrong for many reasons, but the First Amendment as written is not one of them
Attacking the structure of the blood vessel walls makes sense to starve out the tumor for blood, but I'm curious about the long term effect of these "podgy" blood vessels. Large vessels with compromised physical structures stricking around in the long term seem like potential danger on their own. Not nearly as bad as an inoperable brain tumor though. All-in-all, I've more hope for the anti-angiogenesis drugs for the long term, but its good to have something like this for late-discovered tumors.
It can be used in unmodified existing diesel engines. The biggest penetration of this fuel in the market is the conversion of trucking lines and public transportation. Anecdotally, it is much nicer to the engine than petrodiesel.
It is usually synthesized at this point from waste oil used in food preparation, the desposal of which is a bit of an enviromental problem on its own. Two birds, one stone.
Sadly, it is dirtier than hydrogen. In particular, there is some degree of carbon monoxide emission.
My personal suggestion is methanol fuel cells. They can be made and we can synthesize tons of fuel from agricultural waste alone. It works out dirtier than hydrogen, of course, but there is no real bootstrapping problem to produce the fuel cleanly.
I would have to argue that (you keeping your system up to date == you allowing the programmers to make your system more secure)
In a general sense, if the programmers did their job perfectly out of the box, keeping your system up to date would be a moot point, as all the implementation flaws that open up security holes would not exist. The only updates would be feature adds and possibly new, better suited security models.
As it is, we must keep our systems constantly updated because the software is often horribly flawed when we get it, in ways it may take years to discover. Better programming practices and education, as well as large organizations dgoing thorough code reviews in a systematic manner can help security for an overall system a great deal.
Don't get me wrong, the buck stops with the sysadmin in most cases. But without a community dedicated to secure programming practices, even the best sysadmin spends his time running around putting buckets under leaks.
So, then, the socially scarred developer holed up in his parents basement coding all night is not a myth?
Seriously, I think much of open source software begins as something that gets built by an individual to make his job easier, that he decides to feed back to the community. Generally patches are accepted on merit, but many of the authors are more interested in working on it when convenient than becoming a part time project manager for something which they came up with to same them time in the first place.
Excuse my choice of words. You are correct, he was a member of a team, Lead Developer, I think. I merely meant to say he was one of the authors, and thus a likely recipient of licensing dollars. Concerning your other comments, I don't know enough about the technology transfer details to agree or disagree. I will note, however, that the UofI has been perfectly happy to try and sell Mosaic through Spyglass and collect licensing fees for the code in commercial use, so its chance of being true "free as in speech" software might not have been good anyway. And Netscape deserves props for open sourcing Mozilla at a later date.
The possibility of this being a Mosaic hole reminds me of one of life's fun little ironies:
Marc Andreessen wrote Mosaic while at the University of Illinois. After he went on to found Netscape, Microsoft came to an agreement with the University of Illinois to license the Mosaic source code to use it as the core of the Internet Explorer browser. The fact that they still license it is referenced in IE's "About Box". Now the UofI's intellectual property policy is that the creators of the property get ~40% of the licensing money. So, the odds are pretty good that Marc gets annual checks of Microsoft money to pay for his old source code, which was used to destroy his beloved company. Makes me feel bad for him.
Still, it is kind of funny that Microsoft ends up paying some miniscule part of my University salary because they've never been able to write a web browser from scratch.
I seem to recall some software hacking law that allows you (the owner) to reverse-engineer your software, to 1) make it work or 2) to make it work better than it already does. Does this not apply for hardware or embedded software etc?
There is a body of law that would allow you to reverse engineer their hardware under certain circumstances, but it has nothing to do with the issue here. All that law will prevent is them prosecuting you for violating their intellectual property rights. This is a contract law issue
In essence, by agreeing to the EULA, you enter a contract saying that if you modify their hardware, they have the right to drop your service. Now, while the law might protect you from prosecution for reverse engineering, it does not say you get out of your obligations if you enter a contract saying you won't. An it certainly wouldn't require Sonicblue to keep honoring the contract after you've stopped.
I think Sonicblue is covering its ass in a fairly craven manner, but I think its interesting how the situation would be if the EULA was removed from the situation. With no EULA at all, Sonicblue's service would be entirely at will, with the right to cut off your service at any time for any or no reason. While many EULAs are evil, at least they are mostly about defining the company's responsibility to us, rather than vice-versa.
Plus its just damn cool to have nanokernels to show up those microkernel snobs. If the kernels get any smaller, they will be subject to noticeable quantum effects. It will be a little unnerving if my operating system dissolves into a cloud of possible states every time I turn my back.
This is true for people who believe that integer performance is all that matters... but even then, if you do a fair comparison, the G4 gets 2-3 times as much done in a clock cycle. But the reality, these days, is that modern operating systems make extensive use of floating point math, and in this the G4 excels. Hell, the entire UI for Apple will be a 3D rendered surface come the next release, and what isn't off-loaded to the graphics card will be well handled by the G4. The place that integer performance matters a lot is in un-optimized poorly written windowing systems, like Windows and Linux. Those crowds have gone down the path of making poor use of the processor and just buying ever increasing MHz. This puts you further and further behind- as the PowerPC benefits from the same advancements in MHz, the Apple solution gets faster at a much faster rate.
I think you've been led astray, stranger. Virtually all the code of modern operating systems is integer pipeline code, as it should be. Memory management, file i/o, program loading, etc. are just not meaningful floating point tasks. The one aspect of the operating system that stands to make heavy use of the fp pipelines is the GUI renderer, and OSX is the first operating system to really need to consider this, with, lets face it, a computation intensive GUI. Although most of the OSX rendering workload, alpha-transparency calculations, are strictly integer.
One important consideration when you're considering a system with 2 GB ethernet ports on it is how much load this puts on the CPU. For Sun's UltraSparcII based servers, they recommended you budget one CPU for each GB Ethernet adapter in the machine. The reason: all the CPU activity in the TCP/IP stack for that volume of traffic was considerable. Keep in mind, while Sun was suggesting it, their kernel IO was quite good (I don't know how OS X stacks up in this category) and their GB Ethernet adapters were among the best in the industry for low CPU load. So, 2 GB adapters on a low end server is fancy and cool, but don't expect to actually be pushing that many bits through. There is a reason Gigabit Ethernet has won the nickname "200MB Ethernet."
Your 802.11 gear is rated in milliwatts, to get a decent transmission range from 30-100 ft, much less is you have to punch through walls. The alarmists in the original article were expecting a gas station with this lighting to blackout all wirless for a mile. Given the falloff of transmission power being exponential with distance, I doubt a few watt transmitter would do this.
It seems unlikely to me that these things will be all that catastrophic in their effects. To be power-efficeint light sources, each bulb will have limited power with which to generate interference. To be power-efficient enough to make a difference in this market, this technology should probably consume <10 watts for the equivalent of a 60-watt light bulb. Considering that most of that energy will be going into visible light, it can't be a very strong signal source. Even in large installations like gas stations, where many such small sources would exist, the effect should fall off quickly. Don't use them in your home, and your wireless LAN should be safe.
The reason the satelite radio providers are running scared is that these things are mainly slated for use in street lights. Since cars tend to drive under street lights, and car users are the big market for satelite radio, someone's business model will have to give. Even small intereference feilds can be a big problem if they interupt your line of sight, particularly with high frequencies.
At the Univeristy of Illinois, we have a system that does much of what you're looking for, although a foolproof solution is probably not on the market. The network hardware, from Public Port, would tolerate quite a few unreasonable network configurations. You could, for instance, forget that your laptop was statically configed to an IP on one of the campus public networks, and the system wouldn't miss a beat. I've noticed most NAT systems are pretty tolerant of this sort of thing, but this system is seemingly engineered for it. I believe the hardware is currently known as the Tut Systems Expresso SMS/OCS.
Two scenarios are unlikely to work out for you:
Two users on the private network with the same staticly coded IP. With the proliferation of home NAT routers, this is not unlikely.
A user on the private network tries to contact a public IP address claimed by a machine on the private network. This is fairly unlikely.
To get around these possibilities would require each port to be treated like its own NAT domain, as well as some fancy routing logic. I won't say it is impossible, just very complicated.
Slashdot Mirror
I'm familiar of this use of jargon, although not of the intent. To my mind, this has always seemed fairly silly. C defines quite a few high-level constructs which you don't generally see in assembly code. Loops, simple subroutines, pretty much all control structures really. Add to that a typing system that goes well beyond that of the hardware, support for user-defined complex data types, and a robust user library. Yes, these are easily implementable in various assembly languages, but to say they are part of the language is rarely, if ever, true.
My interpretation of the C as assembly code jargon has always been that it combines the low-level power of assembly code with the features of a high-level language.
This did return more results for some search terms than google. Not many of the extras seemed all that useful, though. The signal to noise ratio seems a bit lower.
The ordering of pages seems less helpful. In many cases, the page I'm looking for is farther down the page.
The sponsored links and advertising are way more noticeable, and get in the way of the search results, although they're probably easy enough to ignore.
Google seems to be better at rating by search term proximity, under the useful assumption that if the search terms occur close to each other, it is less likely to be a random hit. One irritation with AllTheWeb is that for many results, it doesn't show you the context of the search terms in the summary.
Obviously AllTheWeb lacks the excellent USENET archive. The video and MP3 search festures might be pretty useful, I haven't had a chance to try them.
I realize I'm coming across as entirely pro-Google, but these are the only observations I have right now. I'll give AllTheWeb a chance, and let internet darwinism settle the issue.
The C programming language is best described as a hardware-independent assembler language.
Ugh. Sorry, but this one is a bit hard to swallow. Bytecode was not a new concept when java hit the schene, but that is no reason confuse portable source from portable binaries. Or to start making high- (or mid-) level languages equivalent to assembly code.
I think Joel starts out with a fairly good idea, which applies well to companies like IBM and HP, and tries to over-apply it. Why be compelled to include the Netscape example, when even he admits it doesn't work? Despite this, I think his observations are fairly insightful.
I didn't suspect this would need clarification, but the point is that if you share network drives with people who have bad email skills, or with people who share systems with them, you can be infected. As an extra bonus, places that let their web designers mount the document tree as a network drive have a nice chance of spreading the virus through downloads, if the serve up any exe's.
Plus, the point isn't if the user can do anything about holes in IE. They still can present a danger that email skills will not protect you from.
Reading press releases from Warner is like watching professional tennis. They seem to jump over the dividing line in consumer rights debates several times a minute.
Boing! Buy Netscape, happy open sourcy browser!
Boing! Build new AOL service around evil
monopolistic browser!
Boing! Buy winamp, make it free!
Boing! All digital devices must have approved copy protection! arrr!
Boing! Rebuild AOL around Mozilla!
Boing! Skipping commercials is theft!
Boing! Macrovision is evil!
Does anyone else get the idea that the merger left these guys with permanant split-brain syndrome?
If you have basic email skills, you're safe.
.jpg and mp3 files with dummy executables that Explorer will foolishly make look like the original files. So common MP3 shares and such make a pretty good vector for crossing the network, as well.
Unfortunatley, this is not entirely true. Quite a few of these viruses are happy to infect non email files once they get on a network via the email vector. We haven't seen many where I work, but we have seen a few that will infect various system files. Then, when a user logs into that system, the virus infected system will gleefully infect any exe's on the network that that user has write access to. Log into a machine like this as a domain administrator, and the chances of it getting to every machine on the network without them opening any email message is quite good.
Some of them will replace
competitively priced notebooks (not to mention sexy)
Brrr... I'm sorry, but I think that Apple, with its "sexy" machines is a major threat to human life on this planet. Apple wants us to redirect all our sexual energy into playing with computers, thus trimming the population growth rate, and making us weak. That way, we will be vulnerable when their teal-plastic-bubble robots move in to take control of the planet.
Sure, it would be a benevolent dictatorship, with easy-to-use interfaces and open standards, but consider the horror when a person's largest muscle is his right index finger, from clicking that one button thousands of times a minute.
Seriously, though, this is not a new tactic from Apple. The lack of a version of Final Cut Pro for Intel platforms has seriously annoyed me for a while. I can see this as a viable way to push their hardware, but I'm not sure they end up making more money by doing so. Limiting one of the best video editing packages to ~10% of the possible market is missing a big oppurtunity.
When it comes down to it, I think Apple's software is what distinguishes it. The interesting form factors they put through are neat, but could be done as well with Intel hardware. Really Apple hardware doesn't do anything Intel hardware can't, except run MacOS. They would sell much more hardware, I think, if it was x86 based. But then they'd have nothing to push their operating system.
So in the end, I have to wonder, is Apple using its software to push the hardware, or its hardware to push the OS platform.
We want ICANN to act like a decent international regulatory body. Having it act no more evil than ANSI of IEEE would be nice. Unfortunately, ICANN has a bit more going for it, mainly:
So, to make sure it acts like a public group and not like a business, we feel the need to place some sort of authoritarian control over it. Since its domain is the world, however, the US government makes little sense for this. How about the UN?
Now I know that many see the UN as either useless or evil, but in certain cases (the World Health Organization, UNICEF,
One of the biggest problems can be lack of compliance to actual or de facto API standards. An OS that doesn't track community standards closely, like my pet peeve, HP-UX, can make a lot of work. Many times, we have been wanting to go forward with a new architecture for some aspect of our systems, only to be held up for quite some time because the software would not compile for HP-UX. The number of open source projects we've needed to port to make them work as well on HP as on Solaris or Linux is considerable. So, keep in mind that sometimes a non-feature like the system library environment can make a lot of difference in running an OS.
I made reference to the difficulty of bootstrapping hydrogen as a fuel source (i.e. creating it without another, equally good and clean source of power). As for pollution, the plants aren't going to remove the carbon monoxide from the air, which was the main point I hoped to make. I personally think Biodiesel is a gret fuel, but one also must acknowledge that it burns dirtier than a process that produces only water vapor. Now efficient large scale biodiesel generators fueling hydrogen production, that might be a beautiful thing. Keep all the organic molecule burning in centralized places where the economy of scale can reduce unburnt fuel, and where high quality air cleaners can be afforded. The best of both worlds.
A few points:
Firstly, I think this trend is a very bad one, but not a sustainable one. It think the medium term effects of this regulatory change will be obvious and will make even fairly jaded political entities scramble to change it back. Firstly, these regulatory changes stand to make most of the providers without last mile networks either go out of business or cut back considerably, something that will be very visible in the current economy. Secondly, a lot of the people who are using broadband now, second-tier adopters, will be pretty damned disillusioned if the providers start screening content. Even if they don't give up on broadband, they'll probably stop evangelizing their mainstream, less geeky friends. I think that sort of thing would slow adoption to a crawl, which the opposite of what the FCC thinks its doing.
Mainly, I think its important to remember that this kind of policy change can be reversed just about instantly. I think the providers know this too, and will not bet the farm that abusing the new state of affairs will not cause such a reversal from future FCC appointees.. In many ways, we'd be much worse off if all of these changes had come through Congress.
Secondly, and more contrarily, I think its rather strange to classify a market media monopoly as a First Amendment violation. The First Amendment has nothing to do with publication. It guarantees that the government will not restrict your voice. It does not guarantee that the government will regulate the market to make people publish that voice. Media monopolies are wrong for many reasons, but the First Amendment as written is not one of them
Attacking the structure of the blood vessel walls makes sense to starve out the tumor for blood, but I'm curious about the long term effect of these "podgy" blood vessels. Large vessels with compromised physical structures stricking around in the long term seem like potential danger on their own. Not nearly as bad as an inoperable brain tumor though. All-in-all, I've more hope for the anti-angiogenesis drugs for the long term, but its good to have something like this for late-discovered tumors.
My personal suggestion is methanol fuel cells. They can be made and we can synthesize tons of fuel from agricultural waste alone. It works out dirtier than hydrogen, of course, but there is no real bootstrapping problem to produce the fuel cleanly.
b) The system was not kept up to date.
I would have to argue that (you keeping your system up to date == you allowing the programmers to make your system more secure)
In a general sense, if the programmers did their job perfectly out of the box, keeping your system up to date would be a moot point, as all the implementation flaws that open up security holes would not exist. The only updates would be feature adds and possibly new, better suited security models.
As it is, we must keep our systems constantly updated because the software is often horribly flawed when we get it, in ways it may take years to discover. Better programming practices and education, as well as large organizations dgoing thorough code reviews in a systematic manner can help security for an overall system a great deal.
Don't get me wrong, the buck stops with the sysadmin in most cases. But without a community dedicated to secure programming practices, even the best sysadmin spends his time running around putting buckets under leaks.
So, then, the socially scarred developer holed up in his parents basement coding all night is not a myth?
Seriously, I think much of open source software begins as something that gets built by an individual to make his job easier, that he decides to feed back to the community. Generally patches are accepted on merit, but many of the authors are more interested in working on it when convenient than becoming a part time project manager for something which they came up with to same them time in the first place.
Excuse my choice of words. You are correct, he was a member of a team, Lead Developer, I think. I merely meant to say he was one of the authors, and thus a likely recipient of licensing dollars. Concerning your other comments, I don't know enough about the technology transfer details to agree or disagree. I will note, however, that the UofI has been perfectly happy to try and sell Mosaic through Spyglass and collect licensing fees for the code in commercial use, so its chance of being true "free as in speech" software might not have been good anyway. And Netscape deserves props for open sourcing Mozilla at a later date.
The possibility of this being a Mosaic hole reminds me of one of life's fun little ironies:
Marc Andreessen wrote Mosaic while at the University of Illinois. After he went on to found Netscape, Microsoft came to an agreement with the University of Illinois to license the Mosaic source code to use it as the core of the Internet Explorer browser. The fact that they still license it is referenced in IE's "About Box". Now the UofI's intellectual property policy is that the creators of the property get ~40% of the licensing money. So, the odds are pretty good that Marc gets annual checks of Microsoft money to pay for his old source code, which was used to destroy his beloved company. Makes me feel bad for him.
Still, it is kind of funny that Microsoft ends up paying some miniscule part of my University salary because they've never been able to write a web browser from scratch.
I seem to recall some software hacking law that allows you (the owner) to reverse-engineer your software, to 1) make it work or 2) to make it work better than it already does. Does this not apply for hardware or embedded software etc?
There is a body of law that would allow you to reverse engineer their hardware under certain circumstances, but it has nothing to do with the issue here. All that law will prevent is them prosecuting you for violating their intellectual property rights. This is a contract law issue
In essence, by agreeing to the EULA, you enter a contract saying that if you modify their hardware, they have the right to drop your service. Now, while the law might protect you from prosecution for reverse engineering, it does not say you get out of your obligations if you enter a contract saying you won't. An it certainly wouldn't require Sonicblue to keep honoring the contract after you've stopped.
I think Sonicblue is covering its ass in a fairly craven manner, but I think its interesting how the situation would be if the EULA was removed from the situation. With no EULA at all, Sonicblue's service would be entirely at will, with the right to cut off your service at any time for any or no reason. While many EULAs are evil, at least they are mostly about defining the company's responsibility to us, rather than vice-versa.
Plus its just damn cool to have nanokernels to show up those microkernel snobs. If the kernels get any smaller, they will be subject to noticeable quantum effects. It will be a little unnerving if my operating system dissolves into a cloud of possible states every time I turn my back.
2. The G4 os SO SLOW!
This is true for people who believe that integer performance is all that matters... but even then, if you do a fair comparison, the G4 gets 2-3 times as much done in a clock cycle. But the reality, these days, is that modern operating systems make extensive use of floating point math, and in this the G4 excels. Hell, the entire UI for Apple will be a 3D rendered surface come the next release, and what isn't off-loaded to the graphics card will be well handled by the G4. The place that integer performance matters a lot is in un-optimized poorly written windowing systems, like Windows and Linux. Those crowds have gone down the path of making poor use of the processor and just buying ever increasing MHz. This puts you further and further behind- as the PowerPC benefits from the same advancements in MHz, the Apple solution gets faster at a much faster rate.
I think you've been led astray, stranger. Virtually all the code of modern operating systems is integer pipeline code, as it should be. Memory management, file i/o, program loading, etc. are just not meaningful floating point tasks. The one aspect of the operating system that stands to make heavy use of the fp pipelines is the GUI renderer, and OSX is the first operating system to really need to consider this, with, lets face it, a computation intensive GUI. Although most of the OSX rendering workload, alpha-transparency calculations, are strictly integer.
One important consideration when you're considering a system with 2 GB ethernet ports on it is how much load this puts on the CPU. For Sun's UltraSparcII based servers, they recommended you budget one CPU for each GB Ethernet adapter in the machine. The reason: all the CPU activity in the TCP/IP stack for that volume of traffic was considerable. Keep in mind, while Sun was suggesting it, their kernel IO was quite good (I don't know how OS X stacks up in this category) and their GB Ethernet adapters were among the best in the industry for low CPU load. So, 2 GB adapters on a low end server is fancy and cool, but don't expect to actually be pushing that many bits through. There is a reason Gigabit Ethernet has won the nickname "200MB Ethernet."
Do you mean to tell me that the technology that kept so many police out of speakeasys has finally been toppled? I'm shocked!
From now on, I'm going to run my systems on authentication via signed permission slips.
Your 802.11 gear is rated in milliwatts, to get a decent transmission range from 30-100 ft, much less is you have to punch through walls. The alarmists in the original article were expecting a gas station with this lighting to blackout all wirless for a mile. Given the falloff of transmission power being exponential with distance, I doubt a few watt transmitter would do this.
It seems unlikely to me that these things will be all that catastrophic in their effects. To be power-efficeint light sources, each bulb will have limited power with which to generate interference. To be power-efficient enough to make a difference in this market, this technology should probably consume <10 watts for the equivalent of a 60-watt light bulb. Considering that most of that energy will be going into visible light, it can't be a very strong signal source. Even in large installations like gas stations, where many such small sources would exist, the effect should fall off quickly. Don't use them in your home, and your wireless LAN should be safe.
The reason the satelite radio providers are running scared is that these things are mainly slated for use in street lights. Since cars tend to drive under street lights, and car users are the big market for satelite radio, someone's business model will have to give. Even small intereference feilds can be a big problem if they interupt your line of sight, particularly with high frequencies.
Two scenarios are unlikely to work out for you:
To get around these possibilities would require each port to be treated like its own NAT domain, as well as some fancy routing logic. I won't say it is impossible, just very complicated.