That was my line, stranger. Can't you come up with your own...?
...and quite ignorant of history.
Actually, no. There's a wonderful document under/usr/share/misc/bsd-family-tree which explains more about the history of BSD than most people know.
The original BSD Unix was BSD-licensed (ever wonder why it was called the BSD license?).
Actually, the original UNIX(tm) was under a restrictive license from AT&T/Bell Labs. People at UCal/Berkeley (and MIT, and CMU, and U-Mich) wrote a bunch of code, notably the TCP/IP stack used almost everywhere nowadays, and ended up re-implementing so much of the proprietary code under the first commonly available Open Source license, that AT&T mostly lost their big lawsuit, but the negotiated settlement requires groups like FreeBSD to call themselves "derived from Unix" rather than claiming to be UNIX(tm).
Some years later, the FSF/GNU project formed to re-implement most of UNIX(tm), then a few years after that, acquired a kernel originally by a clever dude named Linus, thus forming what people call "Linux" or "GNU/Linux". A few years after that, some shiesters at a company called SCO decided to emulate the AT&T lawsuit, with similar lack of results as far as I can tell.
Finally, we catch up to now, where you can tell me about how ignorant you think I am about Unix history.
I don't think you're going to convince many people, though.
Look how far BSD Unix and its derivatives have gotten.
Sure. BSD-derived systems are the second most common platform, after Microsoft Windows. Pure AT&T/SysV-derived UNIX(tm) platforms are dying away mostly, except for Solaris, but MacOS X + FreeBSD + OpenBSD + NetBSD are doing quite well, by-and-large.
Last time I checked, MS wasn't too worried about any of them,
Last time I checked, Microsoft is actively incorporating a bunch of BSD-licensed code; especially in the areas of networking and firewalls: consult the credits for Luigi Rizzo in particular, for example.
Linux, OTOH, is the one drawing all the FUD comments like "anti-american".
Has anyone in this entire discussion about "Linux Kernel Developers' Position on GPLv3" called Linux "anti-american"? Where...?
I don't know what you're getting at with the "X-Windows" stuff, or what you think that has to do with BSD Unix.
Not with BSD Unix, with Linux. If you didn't understand my point, who is it that is confused, exactly?
What does my contributing to the linux kernel have to do with a debate about licenses?
In general, it would add some credibility to your position if you understood what the people writing the code actually care about.
In specific, if you had written some code for the Linux kernel, as an author you would actually have the right to decide which license you want to release your code under. Rather than being in the position of playing "backseat driver" and second-guessing the people who actually do have the right to choose which license(s) to release the code they've written.
This isn't an ad-hominem attack.
Did you say "...and not just sound like ignorant wankers."...?
Calling them "ignorant wankers" sure sounds like an ad-hominem attack to me.
You bet. Obviously the issue is so controversial that wide agreement has not been reached, and may not ever be reached.
Sure, but rehashing the same arguments over and over that have already been addressed in other contexts is not useful discourse.
So you acknowledge that your point about "DRM and patent issues" is "not useful discourse"...? Fine.
Ummm, what are you trying to say here? That a GPLv3 networking library can't link to OpenSSL?
The GPLv3 license has not been finalized, but the proposed no-DRM clauses would certainly appear to forbid the combination of GPLv3 code with the OpenSSL library, which is used for PKI, OpenSSH's authentication, x.509 certs used by SSL webservers, and so forth.
So good job, BSD guys. You almost had us all forced into using Windows, if it weren't for the GPL and Linux saving the day.
You seem to be confused. Maybe, if you accused the BSD camp of forcing people to use MacOS X, you might have something resembling a point. You'd still be wrong, but at least you'd be playing in the right ballpark. But if you feel you've been forced into using Windows, that's your choice and your problem, certainly not that of people writing BSD-licensed code.
Heck, even if you feel forced into running X-Windows-- which might also vaguely resemble a valid point, as I understand that many versions of Linux ship with the X11 Window environment integrated and required to even perform the initial system installation, in contrast to the actual BSD operating systems such as FreeBSD, NetBSD, OpenBSD, DragonFly, and minor variants like PicoBSD or NanoBSD-- X11 is under the MIT license, not BSD.
But don't let the facts get in the way of an otherwise marvellous troll.
Agreed. This position statement seems to be, "We don't like politics and GPLv3, so here are a bunch of bs reasons for opposing the license change."
If you disagree with their position, fine; if you think their reasons are BS, that's your opinion, but the 29 people involved with actually are writing the Linux kernel probably didn't go through the trouble to explain their position in such detail because they thought they position was nothing but BS.
...and not just sound like ignorant wankers.
Just how much of your code is in the Linux kernel today? If the answer is zero, well, you might want to contribute something more useful than a broad ad-hominem attack against the people who actually are writing Linux kernel code.
The DRM and patent issues have been addressed by the FSF a number of times.
You bet. Obviously the issue is so controversial that wide agreement has not been reached, and may not ever be reached.
For the GPLv3 to be usable for general-purpose operating systems, it needs to not forbid mechanisms like/etc/passwd and/bin/login from checking whether a user has a valid password, and it needs to not prevent systems like OpenSSH or OpenSSL from being used with GPLv3 code.
Oh, and corporations may not like it, but since when do corporations like any version of the GPL?
There are plenty of companies who like the GPL just fine; try asking MySQL, or the OSTG (hint: what do you think Slashdot is being run by?)....
Anyway, I think, regardless of what I make, if you make money off of it, I should gain to[o], somehow.
You're welcome to hold that opinion, and you're welcome to write code and license it so that if anyone else resells your software, they owe you a royalty. You should be aware that your software and such a license would not be Open Source or "Free Software". See OSD #1.
Don't be ridiculous. Arranging to have someone killed is not only "wrong," but the very act itself is illegal, regardless of how many details you know.
Murder is "wrong", and is illegal pretty much everywhere that has a functioning government.
However, for better or worse (maybe "better and worse" is a better way of putting it), soldiers and even the police are given the power and authority to use deadly force; not all circumstances where someone kills someone else is "murder". Note that the US government once arranged to have a Japanese admiral killed during WWII based on knowledge gained via MAGIC, the decryption of IJN messages:
...which most people would describe as an "assassination".
However, if I ask a friend to get me a Mt. Dew and he goes to my neighbor, beats the crap out him to get in the house and steals it from his refrigerator, I am not responsible for any of those crimes.
Absolutely. So long as you had no idea and no expectation that your friend would do those acts, you have no responsibility.
Getting back on-topic to the actions taken by HP, do you think that Hurd or Dunn had no idea and no expectation that their investigation of the reporters would involve criminal acts? The email exchanges being released seem to suggest that they'd been given ample notice that the tactics being employed were "grey" to "black", not "pure white". You don't arrange to have people employed at another company under false pretenses in order to spy on that other company legitimately...
So was everyone asleep in that part of computational theory where they point out that everything (including hardware) is reducible to a mathematical algorithm?
In theory, perhaps. More accurately, ideal hardware can be represented or modelled by mathematical algorithms, but real-world hardware exhibits a number of differences from ideal models, including non-perfect TTL response: real transistors aren't ideal binary on-off devices and exhibit non-linear behavior especially as they heat up or run outside of rated tolerances, not that anyone would overclock a circuit or have issues with their CPUs overheating.
Of course, you can model some failure modes, at least once you have enough data to predict the likely ones, but computer manufacturers are in the process of recalling millions of batteries outside of their predicted MTBF, just as some hard drive vendors have had to recall lots of devices because of shoddy components, and there's a whole era of AMD motherboards from the KT266 VIA chipsets through the KT400 or 600 which had those crappy electrolytic capacitors which used to fail after a year or so.
As for computer software, self-contained sections of code working over known data exhibit highly predictable results which can be predicted or modelled deterministicly, but it's easy enough to model algorithms such as the Lorentz attactor or Lyapunov exponents which may be deterministic but are sufficiently non-linear or even chaotic that their states cannot be predicted short of actually computing the results. More to the point, most software nowadays involves interactions with humans which provide more-or-less arbitrary inputs and sometimes you even gets software bugs resulting from un-expected combinations.
It's better to lop off as many software patents as we can, agreed. Litigating patents is usually expensive, but then, having to pay a patent troll royalties for a bogus claim usually becomes expensive, too. Having prior art available to refute a patent troll's claim makes litigating bogus patents a lot easier and a lot cheaper.
I don't believe anything which could be described as an algorithm should be patentable. I also don't believe that you should patent public API's, as such "programming interfaces" are by definition intended for use by other programs; public APIs normally are widely distributed in documentation, which at least prevents others from patenting the APIs which you might release (as your release will obviously constitute prior art). I suppose that if you implement computer software which is sufficiently original, not completely obvious after 5 minutes of thought, and is not representable as a mathematical algorithm, that might deserve the protection of a patent, but for the most part, simple copyright ought to provide enough protection....
Excellent reply; thanks. Of course, I believe the TFA said that astronomers have seen two "puffy" planets out of ten samples being drawn, not just one; but your point about the difference between a PARTICULAR rare item versus a SPECIFIC rare item is still relevant until we get enough samples to have a better feel for the variation out there.
We've observed around 180 exoplanets via Doppler and have ten which perform transits; how many do we have to observe before we start getting a feel for the more common variants versus the rare exceptional categories...?
I agree that is it much easier to detect bigger planets than small ones, and to detect planets close to the star than ones farther out, but the most successful mechanism for detecting planets is the radial-velocity doppler method, which doesn't care how dense the planet is, just how much it weighs. That method can be combined with the transit method to obtain confirmation and a much more accurate estimate of the planet's true mass, for the relatively few number of systems where the geometry is such that we get a transit which can be seen from Earth.
While the doppler method is biased towards noticing heavier planets in terms of mass, it probably isn't biased towards noticing less dense planets.
Certainly, if you take ten samples and you find one of something then it's very likely it's actual rate of occurrence is less than 1/10.
I'm curious to see your reasoning for this. If you know that your sampling is not representative of the population, or you have a reason to suspect a bias which makes it more likely that you are finding instances of the "something" than if you had a lot more samples available, sure, I'd agree with your reasoning.
Agreed-- Darwinia absolutely rocks. I've played, oh twenty or so hours worth, and am just starting Biosphere. How much more is left?
Even if the answer is nothing, well, I've gotten quite a bit of enjoyment for the $10 I paid for the software.
There are some surprisingly good games showing up on Steam that never made it to a store near me or were reviewed high enough for me to order a boxed copy for the original price; now they show up for $10 - 15. Steam isn't perfect-- I wish that it let users roll backward to an older version of something if an update makes changes that I don't like, but several of the companies pushing games to Steam now publish passwords on their webforums for use with Steam.exe's -beta flag, which lets you test out new builds or go back.
Yes. This is also true of external broadband routers, of course, and perhaps even of less intelligent NICs with enough smarts to become confused.
Really dumb NICs aren't bright enough to be hacked, but the smarter ones which offload the stack are more likely to be working with very limited resources like their initial TCP connection table (used for half-open connections during the 3WHS, ie, exchanging SYNs)-- SYN-flooding is more likely to result in a DoS on them then when the host OS is dealing with the TCP/IP stack. Something like the nVidia integrated gigabit NICs with "ActiveArmor" and so forth is probably smart enough to get into trouble.
That is an excellent point; Xanga probably could have saved itself a lot of hassle after-the-fact from the FTC if they had simply done what you suggested to clear their database of under-13 users who had checked the over-13 checkbox initially...
What strikes me odd is that (in my ignorant opinion) a hardware TCP/IP stack should not be too hard to implement
It's not. You can implement a reasonably complete TCP/IP stack by reading RFC-791 through 793 in somewhere around 2000-5000 lines of C code, which boils down to perhaps 64K of ROM/EEPROM space. Takes a month or three of developer time from someone who knows something about what they are doing; less if they've written network stacks before.
so if it does work I imagine that several NIC manufacturers will start offering the feature at a much cheaper price.
They already are. Most decent NICs nowadays come with Rx/Tx checksum offloading, VLAN tagging in hardware, and even interrupt mitigation.
If there's an exploit for your TCP/IP stack on the network card, and it manages to compromise your NIC's tcp/ip, then it's still some way off compromising your host machine's OS? Yes/no?
No such luck. Not when compromising the NIC means you've got control of a busmastering PCI device which can use DMA to scribble malicious code into the host machine's RAM, or, conversely, use DMA to read stuff from the host machine in order to snoop on the user. Note that your standard host-based virus scanner or malware scanner isn't going to have much hope of detecting the compromised code running within the NIC....
It's a daft law, agreed, but when a website asks someone whether they are under 13 and they answer yes, the website is supposed to discard any information they have provided. It's pretty easy to do if you are using something like Apple's WebObjects or another session-based web architecture to implement the website.
Otherwise, everyone goes to iPod and iTunes, and that's not what MS wants.
I think a lot of people have already gone to the iPod and iTunes, not that I have anything against alternatives like SanDisk's new player. But I'd bet that even the people who work for Microsoft are a lot more likely to have an iPod than a Zune player....
Only one-way. GPL can TAKE from any of those licenses, but it can't GIVE to them.
Mixing GPL'ed code with code under some other license does not result in the compilation being under the GPL alone; in that sense, no license can "TAKE" from any other license. It is possible for the author to relicense code under different terms, but unless the existing license gives explicit permission to relicense the code, nobody else has the right to do so.
Let's say I write a program that incorporates some GPL code and I release it under the public domain. Have I violated the GPL?
No. You are welcome to release your own code under whatever terms you wish. You may mix your code with GPL'ed code and redistribute that combination so long as the combination is compliant with the terms of both licenses. The FSF has a page which discusses which licenses are miscable with the GPL, and simple permissive licenses like the BSD/MIT/X11/Zlib licenses, as well as "public domain" are GPL-miscible.
So someone takes a piece of novel code out of the program and does binary only distribution, etc. Where do the various legal responsibilities fall? Does it end up being that the developer of the very first bit of GPL code that forced everything in the chain to be GPL gets to sue, or can anyone on the chain sue (everyone on the chain?) or no one? Or is it simply that there is no violation of copyright here?
If the section being duplicated was part of the stuff you released to the public domain, they are free to do what they like. If the part being copied was under the GPL, then the developer of the first bit of the GPL would have standing to sue for copyright infringement.
(Probably. IANAL, and this kinda thing requires one and the decision of a judge to be certain...)
You're right, of course, that the NeXT boxes were magnesium.
There are several procedures for anodizing metal involving various levels of current and a dye used like paint (only mixed into an acid solution in the anodizing tank, then you apply current to have the dye react with the surface of the metal and form a thin, very hard layer). I suppose the process has more in common with the chemical reaction of a metal primer than it does with classic oil-based or latex paint...
Of course the case isn't airtight.
That's the problem-- having negative partial case pressure relative to ambient (by having fewer intake fans than outtake fans [modulo fan size, speed, etc]) tends to pull dust inside through all of these cracks, notably including any CD-ROM/DVD-ROM/floppy drive you might happen to have.
If you have more intake fans (or airflow volume due to running the intakes faster or whatnot), the dust will be sucked in via them, and can be caught using a removable/cleanable intake filter; the rest of the case & your CD/DVD drive will remain pretty much dust-free, significantly better than the other way.
They've chosen to make those resources freely available, without DRM... clearly, DRM hasn't hampered the flow of information in education in this case. Do you dispute this?
Hell, yes, I dispute this. It's not as if it's really a matter of opinion: go find and ask ten librarians and ten teachers whether DRM has in fact hampered the flow of information for them.
The preferred way to install an app on MacOS is to put everything it needs into the bundle and use drag-n-drop to install or deinstall it (ie, drag it to the trash).
However, if a subcomponent being depended upon is large enough or provides functionality which is expected to be widely shared with other apps, and it might be useful as a separate thing, MacOS X packages can do this by installing subcomponents, and the framework versioning does a good job of handling multiple versions of a framework if you need to run an old and new version of some app for whatever reason.
They're called.mpkg's rather than just.pkgs (multiple packages).
Also note that there's a huge hairy buttload of standard APIs available with MacOS X and they are generally pretty stable, it's not as if normal MacOS apps have to bundle the latest DirectX, a sound library, an AVI player, and a few OS patches just to get a random game playing properly. (Try searching for eax*.dll or bink*.dll on a Windows gaming machine and ask yourself what's going on there...)
Unix and Linux systems handle pure libraries OK via shared version numbers, although failing to bump #'s when an API changes is not uncommon and it can really screw complex programs up, but external resources like images, machine-independant data files, and so forth often collide on a pure Unix environment.
As for Windows, it can't even deal with installing a new version of a file in place which is being used by existing processes without rebooting, much less avoid DLL conflicts.
Re:They are missing the lesson of failing companie
on
AOL 9.0 Called Badware
·
· Score: 1
I swore your comment said "When you are an a hole, stop digging."
Err? After reading the parent comment, it took me a remarkably long time to figure out yours.:-)
And I was ready to agree too
Absolutely. I would be afraid of anyone who asked, "Is that an entrenching tool, or are you just happy to see me?"
Slashdot Mirror
That was my line, stranger. Can't you come up with your own...?
Actually, no. There's a wonderful document under /usr/share/misc/bsd-family-tree which explains more about the history of BSD than most people know.
The original BSD Unix was BSD-licensed (ever wonder why it was called the BSD license?).
Actually, the original UNIX(tm) was under a restrictive license from AT&T/Bell Labs. People at UCal/Berkeley (and MIT, and CMU, and U-Mich) wrote a bunch of code, notably the TCP/IP stack used almost everywhere nowadays, and ended up re-implementing so much of the proprietary code under the first commonly available Open Source license, that AT&T mostly lost their big lawsuit, but the negotiated settlement requires groups like FreeBSD to call themselves "derived from Unix" rather than claiming to be UNIX(tm).
Some years later, the FSF/GNU project formed to re-implement most of UNIX(tm), then a few years after that, acquired a kernel originally by a clever dude named Linus, thus forming what people call "Linux" or "GNU/Linux". A few years after that, some shiesters at a company called SCO decided to emulate the AT&T lawsuit, with similar lack of results as far as I can tell.
Finally, we catch up to now, where you can tell me about how ignorant you think I am about Unix history.
I don't think you're going to convince many people, though.
Look how far BSD Unix and its derivatives have gotten.
Sure. BSD-derived systems are the second most common platform, after Microsoft Windows. Pure AT&T/SysV-derived UNIX(tm) platforms are dying away mostly, except for Solaris, but MacOS X + FreeBSD + OpenBSD + NetBSD are doing quite well, by-and-large.
Last time I checked, MS wasn't too worried about any of them,
Last time I checked, Microsoft is actively incorporating a bunch of BSD-licensed code; especially in the areas of networking and firewalls: consult the credits for Luigi Rizzo in particular, for example.
Linux, OTOH, is the one drawing all the FUD comments like "anti-american".
Has anyone in this entire discussion about "Linux Kernel Developers' Position on GPLv3" called Linux "anti-american"? Where...?
I don't know what you're getting at with the "X-Windows" stuff, or what you think that has to do with BSD Unix.
Not with BSD Unix, with Linux. If you didn't understand my point, who is it that is confused, exactly?
PS: Have a nice day, stranger....
In general, it would add some credibility to your position if you understood what the people writing the code actually care about.
In specific, if you had written some code for the Linux kernel, as an author you would actually have the right to decide which license you want to release your code under. Rather than being in the position of playing "backseat driver" and second-guessing the people who actually do have the right to choose which license(s) to release the code they've written.
This isn't an ad-hominem attack.
Did you say "...and not just sound like ignorant wankers."...?
Calling them "ignorant wankers" sure sounds like an ad-hominem attack to me.
You bet. Obviously the issue is so controversial that wide agreement has not been reached, and may not ever be reached.
Sure, but rehashing the same arguments over and over that have already been addressed in other contexts is not useful discourse.
So you acknowledge that your point about "DRM and patent issues" is "not useful discourse"...? Fine.
Ummm, what are you trying to say here? That a GPLv3 networking library can't link to OpenSSL?
The GPLv3 license has not been finalized, but the proposed no-DRM clauses would certainly appear to forbid the combination of GPLv3 code with the OpenSSL library, which is used for PKI, OpenSSH's authentication, x.509 certs used by SSL webservers, and so forth.
You seem to be confused. Maybe, if you accused the BSD camp of forcing people to use MacOS X, you might have something resembling a point. You'd still be wrong, but at least you'd be playing in the right ballpark. But if you feel you've been forced into using Windows, that's your choice and your problem, certainly not that of people writing BSD-licensed code.
Heck, even if you feel forced into running X-Windows-- which might also vaguely resemble a valid point, as I understand that many versions of Linux ship with the X11 Window environment integrated and required to even perform the initial system installation, in contrast to the actual BSD operating systems such as FreeBSD, NetBSD, OpenBSD, DragonFly, and minor variants like PicoBSD or NanoBSD-- X11 is under the MIT license, not BSD.
But don't let the facts get in the way of an otherwise marvellous troll.
If you disagree with their position, fine; if you think their reasons are BS, that's your opinion, but the 29 people involved with actually are writing the Linux kernel probably didn't go through the trouble to explain their position in such detail because they thought they position was nothing but BS.
Just how much of your code is in the Linux kernel today? If the answer is zero, well, you might want to contribute something more useful than a broad ad-hominem attack against the people who actually are writing Linux kernel code.
The DRM and patent issues have been addressed by the FSF a number of times.
You bet. Obviously the issue is so controversial that wide agreement has not been reached, and may not ever be reached.
For the GPLv3 to be usable for general-purpose operating systems, it needs to not forbid mechanisms like /etc/passwd and /bin/login from checking whether a user has a valid password, and it needs to not prevent systems like OpenSSH or OpenSSL from being used with GPLv3 code.
Oh, and corporations may not like it, but since when do corporations like any version of the GPL?
There are plenty of companies who like the GPL just fine; try asking MySQL, or the OSTG (hint: what do you think Slashdot is being run by?)....
You're welcome to hold that opinion, and you're welcome to write code and license it so that if anyone else resells your software, they owe you a royalty. You should be aware that your software and such a license would not be Open Source or "Free Software". See OSD #1.
Murder is "wrong", and is illegal pretty much everywhere that has a functioning government.
However, for better or worse (maybe "better and worse" is a better way of putting it), soldiers and even the police are given the power and authority to use deadly force; not all circumstances where someone kills someone else is "murder". Note that the US government once arranged to have a Japanese admiral killed during WWII based on knowledge gained via MAGIC, the decryption of IJN messages:
Wikipedia on Yamamoto
...which most people would describe as an "assassination".
However, if I ask a friend to get me a Mt. Dew and he goes to my neighbor, beats the crap out him to get in the house and steals it from his refrigerator, I am not responsible for any of those crimes.
Absolutely. So long as you had no idea and no expectation that your friend would do those acts, you have no responsibility.
Getting back on-topic to the actions taken by HP, do you think that Hurd or Dunn had no idea and no expectation that their investigation of the reporters would involve criminal acts? The email exchanges being released seem to suggest that they'd been given ample notice that the tactics being employed were "grey" to "black", not "pure white". You don't arrange to have people employed at another company under false pretenses in order to spy on that other company legitimately...
In theory, perhaps. More accurately, ideal hardware can be represented or modelled by mathematical algorithms, but real-world hardware exhibits a number of differences from ideal models, including non-perfect TTL response: real transistors aren't ideal binary on-off devices and exhibit non-linear behavior especially as they heat up or run outside of rated tolerances, not that anyone would overclock a circuit or have issues with their CPUs overheating.
Of course, you can model some failure modes, at least once you have enough data to predict the likely ones, but computer manufacturers are in the process of recalling millions of batteries outside of their predicted MTBF, just as some hard drive vendors have had to recall lots of devices because of shoddy components, and there's a whole era of AMD motherboards from the KT266 VIA chipsets through the KT400 or 600 which had those crappy electrolytic capacitors which used to fail after a year or so.
As for computer software, self-contained sections of code working over known data exhibit highly predictable results which can be predicted or modelled deterministicly, but it's easy enough to model algorithms such as the Lorentz attactor or Lyapunov exponents which may be deterministic but are sufficiently non-linear or even chaotic that their states cannot be predicted short of actually computing the results. More to the point, most software nowadays involves interactions with humans which provide more-or-less arbitrary inputs and sometimes you even gets software bugs resulting from un-expected combinations.
It's better to lop off as many software patents as we can, agreed. Litigating patents is usually expensive, but then, having to pay a patent troll royalties for a bogus claim usually becomes expensive, too. Having prior art available to refute a patent troll's claim makes litigating bogus patents a lot easier and a lot cheaper.
I don't believe anything which could be described as an algorithm should be patentable. I also don't believe that you should patent public API's, as such "programming interfaces" are by definition intended for use by other programs; public APIs normally are widely distributed in documentation, which at least prevents others from patenting the APIs which you might release (as your release will obviously constitute prior art). I suppose that if you implement computer software which is sufficiently original, not completely obvious after 5 minutes of thought, and is not representable as a mathematical algorithm, that might deserve the protection of a patent, but for the most part, simple copyright ought to provide enough protection....
Excellent reply; thanks. Of course, I believe the TFA said that astronomers have seen two "puffy" planets out of ten samples being drawn, not just one; but your point about the difference between a PARTICULAR rare item versus a SPECIFIC rare item is still relevant until we get enough samples to have a better feel for the variation out there.
We've observed around 180 exoplanets via Doppler and have ten which perform transits; how many do we have to observe before we start getting a feel for the more common variants versus the rare exceptional categories...?
I agree that is it much easier to detect bigger planets than small ones, and to detect planets close to the star than ones farther out, but the most successful mechanism for detecting planets is the radial-velocity doppler method, which doesn't care how dense the planet is, just how much it weighs. That method can be combined with the transit method to obtain confirmation and a much more accurate estimate of the planet's true mass, for the relatively few number of systems where the geometry is such that we get a transit which can be seen from Earth.
While the doppler method is biased towards noticing heavier planets in terms of mass, it probably isn't biased towards noticing less dense planets.
I'm curious to see your reasoning for this. If you know that your sampling is not representative of the population, or you have a reason to suspect a bias which makes it more likely that you are finding instances of the "something" than if you had a lot more samples available, sure, I'd agree with your reasoning.
Agreed-- Darwinia absolutely rocks. I've played, oh twenty or so hours worth, and am just starting Biosphere.
How much more is left?
Even if the answer is nothing, well, I've gotten quite a bit of enjoyment for the $10 I paid for the software.
There are some surprisingly good games showing up on Steam that never made it to a store near me or were reviewed high enough for me to order a boxed copy for the original price; now they show up for $10 - 15. Steam isn't perfect-- I wish that it let users roll backward to an older version of something if an update makes changes that I don't like, but several of the companies pushing games to Steam now publish passwords on their webforums for use with Steam.exe's -beta flag, which lets you test out new builds or go back.
Yes. This is also true of external broadband routers, of course, and perhaps even of less intelligent NICs with enough smarts to become confused.
Really dumb NICs aren't bright enough to be hacked, but the smarter ones which offload the stack are more likely to be working with very limited resources like their initial TCP connection table (used for half-open connections during the 3WHS, ie, exchanging SYNs)-- SYN-flooding is more likely to result in a DoS on them then when the host OS is dealing with the TCP/IP stack. Something like the nVidia integrated gigabit NICs with "ActiveArmor" and so forth is probably smart enough to get into trouble.
That is an excellent point; Xanga probably could have saved itself a lot of hassle after-the-fact from the FTC if they had simply done what you suggested to clear their database of under-13 users who had checked the over-13 checkbox initially...
It's not. You can implement a reasonably complete TCP/IP stack by reading RFC-791 through 793 in somewhere around 2000-5000 lines of C code, which boils down to perhaps 64K of ROM/EEPROM space. Takes a month or three of developer time from someone who knows something about what they are doing; less if they've written network stacks before.
so if it does work I imagine that several NIC manufacturers will start offering the feature at a much cheaper price.
They already are. Most decent NICs nowadays come with Rx/Tx checksum offloading, VLAN tagging in hardware, and even interrupt mitigation.
No such luck. Not when compromising the NIC means you've got control of a busmastering PCI device which can use DMA to scribble malicious code into the host machine's RAM, or, conversely, use DMA to read stuff from the host machine in order to snoop on the user. Note that your standard host-based virus scanner or malware scanner isn't going to have much hope of detecting the compromised code running within the NIC....
It's a daft law, agreed, but when a website asks someone whether they are under 13 and they answer yes, the website is supposed to discard any information they have provided. It's pretty easy to do if you are using something like Apple's WebObjects or another session-based web architecture to implement the website.
I think a lot of people have already gone to the iPod and iTunes, not that I have anything against alternatives like SanDisk's new player. But I'd bet that even the people who work for Microsoft are a lot more likely to have an iPod than a Zune player....
Mixing GPL'ed code with code under some other license does not result in the compilation being under the GPL alone; in that sense, no license can "TAKE" from any other license. It is possible for the author to relicense code under different terms, but unless the existing license gives explicit permission to relicense the code, nobody else has the right to do so.
No. You are welcome to release your own code under whatever terms you wish. You may mix your code with GPL'ed code and redistribute that combination so long as the combination is compliant with the terms of both licenses. The FSF has a page which discusses which licenses are miscable with the GPL, and simple permissive licenses like the BSD/MIT/X11/Zlib licenses, as well as "public domain" are GPL-miscible.
So someone takes a piece of novel code out of the program and does binary only distribution, etc. Where do the various legal responsibilities fall? Does it end up being that the developer of the very first bit of GPL code that forced everything in the chain to be GPL gets to sue, or can anyone on the chain sue (everyone on the chain?) or no one? Or is it simply that there is no violation of copyright here?
If the section being duplicated was part of the stuff you released to the public domain, they are free to do what they like. If the part being copied was under the GPL, then the developer of the first bit of the GPL would have standing to sue for copyright infringement.
(Probably. IANAL, and this kinda thing requires one and the decision of a judge to be certain...)
You're right, of course, that the NeXT boxes were magnesium.
There are several procedures for anodizing metal involving various levels of current and a dye used like paint (only mixed into an acid solution in the anodizing tank, then you apply current to have the dye react with the surface of the metal and form a thin, very hard layer). I suppose the process has more in common with the chemical reaction of a metal primer than it does with classic oil-based or latex paint...
Of course the case isn't airtight. That's the problem-- having negative partial case pressure relative to ambient (by having fewer intake fans than outtake fans [modulo fan size, speed, etc]) tends to pull dust inside through all of these cracks, notably including any CD-ROM/DVD-ROM/floppy drive you might happen to have. If you have more intake fans (or airflow volume due to running the intakes faster or whatnot), the dust will be sucked in via them, and can be caught using a removable/cleanable intake filter; the rest of the case & your CD/DVD drive will remain pretty much dust-free, significantly better than the other way.
Hell, yes, I dispute this. It's not as if it's really a matter of opinion:
go find and ask ten librarians and ten teachers whether DRM has in fact hampered the flow of information for them.
The preferred way to install an app on MacOS is to put everything it needs into the bundle and use drag-n-drop to install or deinstall it (ie, drag it to the trash).
.mpkg's rather than just .pkgs (multiple packages).
However, if a subcomponent being depended upon is large enough or provides functionality which is expected to be widely shared with other apps, and it might be useful as a separate thing, MacOS X packages can do this by installing subcomponents, and the framework versioning does a good job of handling multiple versions of a framework if you need to run an old and new version of some app for whatever reason.
They're called
Also note that there's a huge hairy buttload of standard APIs available with MacOS X and they are generally pretty stable, it's not as if normal MacOS apps have to bundle the latest DirectX, a sound library, an AVI player, and a few OS patches just to get a random game playing properly. (Try searching for eax*.dll or bink*.dll on a Windows gaming machine and ask yourself what's going on there...)
Unix and Linux systems handle pure libraries OK via shared version numbers, although failing to bump #'s when an API changes is not uncommon and it can really screw complex programs up, but external resources like images, machine-independant data files, and so forth often collide on a pure Unix environment.
As for Windows, it can't even deal with installing a new version of a file in place which is being used by existing processes without rebooting, much less avoid DLL conflicts.
Err? After reading the parent comment, it took me a remarkably long time to figure out yours. :-)
And I was ready to agree too
Absolutely. I would be afraid of anyone who asked, "Is that an entrenching tool, or are you just happy to see me?"