Perhaps if Slashdot allows moderators to report comments containing illegal material and appoints someone to remove such material, we could avoid future conflicts...
...Slashdot should not be held responsible for users' comments.
Unfortunately, the moment that Slashdot directly or indirectly removes a post due to content, Slashdot becomes responsible, both in conventional and legal terms, for all user-submitted content on the site.
This is one of the primary reasons that the Slashdot editors have refused to remove posts in the past -- to do it voluntarily once (for any reason) means that they would be legally obligated to do so in the future (for any reason).
I think it's also important to draw a distinction between legality and ethics here: what Microsoft has done is to effectively apropriate an academically developed public standard, developed in large part with public funds. Think about that a second. Is that very ethical?
Ironically, due to the current state of law, what Microsoft has done is legal, and the public really has no direct legal recourse (the DOJ trial doesn't count, you can't add new charges after the verdict). Under these circumstances, while Slashdot readers posting the specification is unquestionably illegal, I have a very hard time convincing myself it was unethical.
In the long view, I think that this is (deliberately or not) about changing unethical laws, not just challenging unethical practices.
I just hope that the people posting the specifications really understand what civil disobedience is about -- they can be tracked down, and they should fully expect to be punished for breaking the law. As I understand it, under the DMCA, their circumvention of a copy-protection measure for any reason is a felony.
It would seem that what the WinGate proxy does is to simply redirect all UDP traffic to ALL hosts on the network -- at least the local subnet... the shotgun approach basically. The theory being that the ones that don't care about the data won't be listening, and won't see it.
They normally don't.
Consequently, it may be possible to tell ipchains to MASQ UDP packets to the network broadcast address, meaning that all the machines on the subnet will get them.
As long as you don't do this for any important ports (DNS, et al), you should be OK. Although the security guru in me is still screaming bloody murder.
So? You've got search permission.
on
Netscape 6
·
· Score: 2
That should at least allow you to access/stat files/subdirectories. Of course, if you don't have at least search on the subdirs and read on the file, you're still screwed.
... or is that netscape6 the one inside blind?... in that case, I guess we're both right.
Nope... existing laws do just fine, thanks...
on
Netscape 6
·
· Score: 2
This is a big issue for OSS projects. If you get a good one going. MS (insert evil closed source company) can copy the fruits of your labor and incorporate it into their monopoly continuing software. And you can't stop them or prove that they did it (without some new laws).
Nope, existing copyright law does just fine. Except for BSD or X licenses (where the point is actually that companies like MS _can_ use the code if they want), incorporation into a closed-source product would be in violation of the terms of the license.
As for proving that they've taken code, that's no easier to prove than for closed-source software, where your competitor may have managed to appropriate your source code through industrial espionage, or just snagging what had been a legal copy of the code floating around. You'd be suprised at how freely even the source code to Windows NT flows, especially at some educational institutions.
What makes GNU tools the defacto standard when none of the other equivalents use their "extensions"? If they were the standard, the others would add those additional options.
You obviously haven't spent very much time using proprietary Unices. For example, HP-UX's sed(1) doesn't seem to have been significantly updated since about 1983. Beleagured sysadmins like myself usually just say "fuck this" and install the GNU tools.
Example, the GNU automake/autoconf generates makefiles that are only usable with gmake.
The gmake dependencies are there, but only with automake, not autoconf by itself. Really, gmake dependencies are the only real problem that I've ever encountered out of your list.
Example, shell scripts from GNU are invariably designed for bash and not generic sh.
I honestly haven't had any problems with GNU shell scripts on any systems with a POSIX-compliant shell. (There are some Unices still floating around with a/bin/sh that is not fully POSIX-compliant). You're more likely to get bitten by differences in the supporting tools.
People who write shell scripts on GNU platforms do get sloppy with portability, yes, but that's not specific to GNU platforms.
Example, most GNU software requires the extensions in glibc, and will not work with any other C library.
Whoa whoa whoa... now that's just patently false. I mean, just consider the fact that the GNU tools ship for a large number of platforms without the GNU library (e.g. FreeBSD, Win32, even VMS... eep!).
Even that aside, I've personally built and installed the vast majority of the GNU tools on a stock HP-UX 10.20 system. Everything seems to work fine, and the only caveat was that I needed to build and install GNU make first to build some packages that used automake.
So, no offense, but at least based on my own experience, I'd have to say that the claim that GNU tools are all dependent on the GNU C library is complete bullshit.
FreeBSD isn't a distribution of the GNU system, it's an entirely different system that happens to come with GNU tools extra.
If you removed all the GNU tools from a stock FreeBSD installation, it would still boot and basically everything would work.
All current Linux distributions are GNU systems, however. The core system around the kernel is all GNU software.
Remove all the GNU tools and libraries from a stock Linux system, and you'll be lucky if you can get as far as a single-user shell, let alone/sbin/init.
Now, Tom Christianson (the Perl guy) had the idea a while back of creating a GNU distribution, but using the FreeBSD kernel. That would be a GNU system, and for that particular system, the GNU/FreeBSD moniker would be appropriate (although I doubt that was his intent).
Alternatively, if you replaced the GNU tools of a Linux distribution with the FreeBSD tools and libraries (after making appropriate changes to accomodate the kernel differences), you'd have something that you could justifiably call FreeBSD/Linux (that would be a much more constructive use of Tom's time, I think).
1. Iridium just happens to transmit on a radio band that radio telescopes listen to. Whoops.
2. The satelites are low enough, and have such a profile that sunlight reflecting off of them (even when it's night on the surface, the satelites are still out far enough that they may not be in Earth's shadow) can create bright flashes that can damage or destroy (expensive!) sensitive telescope optics.
The latter is a problem with other satelites too (to a small extent), but Iridium is by far the most severe.
...what they're getting into. (assuming for the moment that they're legit)
I kind of resent their abuse of the term "open source", too.
It's not as if you can just buy the birds so the old owners won't crash them. There's a lot of maintainence work that has to go on... continuously...
You then have to deal with them when they break (either write the affected satelite off, or see if you can engineer a workaround from the ground).
You have to keep them out of trouble.
You have to turn and shut them down at critical moments so the delicate bits won't get fried by solar flares, hit by flying bits of space junk (which you have to track relative to your birds and figure out if you need to worry about a particular item), or damaged by any other number of interesting astronomical "events".
You have to nudge them back into their orbits periodically to keep them from reentering and burning up early, screwing up other satelites, and just generally not being where they need to be to do their job.
It's a lot like taking care of a herd of 66 insanely expensive flying metal sheep, really. Remotely.
Ever since they've been launched, the Iridium satelites have been royally fucking up earth-based astronomy, too.
So, it's a lot like having a huge herd of 66 insanely expensive flying metal sheep that poop on everyone's lawn, so everyone hates them.
Oh, and they're in a low-earth orbit, too, which means their orbit isn't going to last that much longer anyway (five, ten years?...the original plan was to keep launching satelites as the old ones expired... I don't think these "saveIridum" folks are prepared to do that). I hope these "open source Iridium" people (I really dislike their abuse of the moniker) are capable of deorbiting them safely, and in a controlled fashion, when the time does come.
(and when they come down they very likely might come down over major population centers if you don't know what you're doing... the current owners at least know what they are doing)
(although I should note for the sake of the/. alarmists, that they'd probably just burn up in the atmosphere... you still don't want to take those kind of chances, though!)
So, really, it's a lot like having no experience, buying a herd of 66 insanely expensive flying metal sheep that everyone hates because they poop on their lawn, and which are going to die soon anyway... with the potential of severe (but spectacular) property damage... and then calling it "open source".
Fortunately, looking at their page, it looks like they have about as many financial backers as they do clues... so, in conclusion, I'm very thankful that this "open source Iridium" thing is unlikely to succeed, if nothing else for the sake of the "open source" reputation.
X11 is still a great protocol for network transparent windowing
Really?
it's efficient
Only if you consider marshalling/unmarshalling individual drawing primitives across some sort of IPC (network or local) efficient. No, I'm not advocating direct application hardware access. Think outside the box, and maybe go back and look at how systems like NeWS, Display Postscript and Berlin are designed.
conceptually simple
No, not really. Try writing a window manager sometime. The original idea was (is) pretty simple, but once you start adding the various standard extensions that accumulated over the years, if you're writing something major, it's a real mind-bending mess. You're fortunate nowadays that GTK+ and Qt hide a lot of the evil from you.
mature
No argument there; X is tried, true, and it works.
In those areas where it really matters (bulk image and geometry transfer, 3D graphics) X11 already gives applications memory mapped access.
That doesn't help you if you're remote... and yes those are nice sometimes if you're remote.
X11 does lack a few features, like antialiased drawing and fonts. Those can be added easily with X11's well-defined and widely used extension mechanism, and without breaking backwards compatibility.
Ever wonder why that hasn't been done yet? It's because most people who thought about it decided it wasn't worth the trouble: existing applications might run, but they wouldn't get the new functionality (i.e. antialiased characters). They would still still require a rewrite (yes, a rewrite, not just recompiling). The APIs and necessary backend code are just necessarily that different, because the original X ones were designed so badly.
[To be fair, the situation is a little better now, just because modern toolkits abstract the stuff enough that you could get by with only minor changes to the library APIs... in most cases you'd just have to recompile the apps that didn't use the changed APIs, and only make minor changes to the ones that did, or that bypassed the library in some way]
If the antialiased font server was backwards compatible, it would only be because it kept the entire old (now redundant) architecture and API, in addition to implementing the new one.
The necessity of taking this approach to extend other aspects of X is one of the contributing factors to its bloat over the years.
Using libraries that access the frame buffer directly does make sense for embedded systems, but for general usage, they would represent a big step backwards.
Agreed, for the most part. However, arbitrated (i.e. not totally unsupervised) hardware access is still good for certain classes of specialized applications, and of course games. That's the need that ultimately spawned fbcon and KGI (the GGI kernel layer).
Something to ponder in parting... if someone wants to experiment with a windowing system that is not X, they either need to rewrite all the drivers themselves, run under X (...then what's the point?) or they need to have some kind of non-X driver infrastructure availible.
i.e. has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix?
Here's my question. Can licenses be applied to patches?
Yes. Patches in excess of 10 LOC are copyrightable (and thus under current law implicitly copyrighted) material. (the 10 LOC is a matter of legal precedent)
Here's my point - are patches covered under the GPL (or any license?).
Yes. See above
If yes, what's going to stop someone from creating a Artistic license patch for Linux the linux kernel? Or a Sun Community License? Or a completely proprietery license?
... nothing... I don't see the problem there.
Remember, what LAME does is GPL-infect a piece of code that is has no copyright on, simply by patching it.
I believe you misunderstand the nature of GPL "infection". What you end up with is a compound work carrying the copyrights (and respective licenses) of _both_ copyright holders, each retaining copyright on the portions of the work they contributed. No license is changed.
If the licenses are compatible (e.g. not contradictory -- this is the case with LAME and the ISO encoder), you're fine. If not, you just have a compound work that is illegal to distribute.
Under copyright law, you have no rights to do anything with a copyrighted work except those explicitly granted you by the copyright holder(s) through licensing, and those rights granted you by law and legal precedent (i.e. fair use).
Therefore, if the "compound license" is "impossible" (self-contradictory), then you have no license, and thus no legal right to redistribute the compound work.
It is certainly possible and legal to make a patch for the Linux kernel under a proprietary license, but it would still be illegal to distribute a Linux kernel (in source or binary form) with the patch applied, without prior permission from the copyright holders of the Linux kernel (which in practical terms would mean you being given a copy with a license other than GPL to have your way with).
Soft realtime (the announcement in the article regards hard realtime; see other comments for the distiction) generally does good enough. I'm in the habit of running my X server and window manager with realtime priority on slower machines (when I'm not doing anything else compute-intensive that I care about). It does make a big difference in that regard -- where the problem actually is CPU contention, anyway...
So, it's not a matter of starting over, just a matter of selecting another one of the existing Linux schedulers. (this operation is NOT, I repeat NOT synonymous with nice(2) -- see sched_setscheduler(2) and friends)
I actually wrote a set of tools that allow you to manipulate the realtime schedulers under Linux (soft realtime was introduced in Linux 1.3.something, if I remember correctly), and they're on freshmeat as rt-utils.
The homepage, and download links are out-of-date, but I'll get around to dealing with that soon. In the meantime, if you want a copy, drop a line to mental@rydia.net
... this once, at the top of the file (the HTML comments are optional -- just there to prevent the CSS code from showing up in non-CSS browsers), instead of having:
<FONT FACE="BastardWeird">...</FONT>
... around every single H1 in the document. That's a savings of about 39 bytes PER H1, after an initial cost of about 70 bytes. Maybe H1 is a bad example (it doesn't get used more than once or twice in a document usually), but this extends to other tags too, and not just to fonts. CSS also replaces FONT COLOR and a lot of other things that before needed to be coded multiple times into the same HTML document.
This is an even bigger win when you use a single, central css file (referenced via LINK REL=stylesheet), rather than coding CSS into every document. Maintainence also magically becomes easier. Want to change your whole site's look? Edit one file.
The only reason Open Source works is that everybody donates their time, and do something else to eat. If everybody got paid for what they did, all the software would be better, but how are you going to pay everybody.
I've been paid to work on open source software -- but, I wasn't been paid for the software I wrote, I was paid for the work I did. Most programmers are paid like that anyway -- what percentage of programmers of closed-sources software do you know who get per-copy royalties? (the answer: very few. even the ones who freelance are typically paid by the hour, not per copy of software used)
I don't think charging consumers per-copy is really fair, given that the programmers typically never get any of it anyway. We may as well stop trying to pretend programming isn't a service, and focus on funding software development appropriately.
I dunno, probably interferometry techniques applied to diffuse reflection. Unlikely to ever be as accurate as in the movie, however. (accuraccy in "unseen" regions would also degrade exponentially with distance)
Probably be a matter of iteratively refining a volumetric model from initial heuristic "guesses", I suppose. Most wrong guesses would be detectable as the results would visibly lose self-consistency after the first few iterations.
(also a good way to detect doctored images, although I daresay there are easier and more efficient ways of detecting those)
although even a line of original GPL code is enough to keep it under the GPL
Actually I believe the legal precedent is that that about 10 LOC is about the limit for copyright protection (regardless of license).
There's nothing to see here, you can go home now..
on
Hole in GNU GPL?
·
· Score: 3
This guy's entire argument seems to be based on the (false) assumption that corporations are not legally bound by contracts/licences as individuals are. In actuality, the very PURPOSE of incorporation is to create a new legal entity (sort of a fake person) that can take legal responsibility for its own actions, rather than the company's head being explicitly liable. To put this another way: if corporations weren't bound by licenses as individuals are, why do they even bother to license software (under any license, even proprietary licenses) from each other? Why do CORPORATIONS put their copyright on code they produce, rather than the individual programmers working for them? This supposed "hole" is bogus.
So if Microsoft suddenly enforced this law in the US, and by accident one of the disabling emails went to a user in the UK, then Bill Gates or Ballmer would get an extradition notice because they are ultimately liable for Microsofts software.
No, they're not personally liable. Liability is held by the incorporated legal entity "Microsoft". That's one of the functions of incorporation, in fact -- a corporation becomes its own legal "person", accountable for its own actions, independent of any of its members. More or less.
Because the length of copyright protection has been continuously extended, almost nothing's gone into the public domain since World War II.
Copyright protection is now for such a long period of time that the "limited monopoly for long enough to compensate the author/artist, then let it become public domain to encourage the advancement of the arts" model is completely broken.
So you are saying, that we are getting often files slower than we could on the same connection for some rason that is in stack? Then we gotto remove that stupid limit NOW. I want my modem work at it's fullest.
Then the Internet collapses as all the major backbones get saturated, and the world as we know it ends. Tragedy of the Commons, my friend.
A friend of mine who does GBC development told me that Nintendo (like most console/handheld makers) makes money by selling their stations/handhelds at a loss, and making up for it by the licensing fees they charge developers. Consequently, they have a pattern of working hard to crush the "hobbyist" development community, since hobbyists don't generally pay licensing fees. As if Nintendo really needed the additional money...
Wouldn't an open source credit card verification system be a Bad Thing(tm)? I would assume that this would make it easier to engineer the ablility to compromise the transaction. I know that security through obscurity is a bad policy by nature, but in these types of things, is it not required?
Not really, no. Well-designed secure protocols retain their security even when all of the participants know all the details of the protocol, and even when one or more of the participants is malicious.
If it makes a difference whether or not people know the full protocol, then it's a sign that the protocol isn't really secure in the first place. It's a sign that you already have a problem.
If you're relying on secrecy of the protocol to protect the integrity of the protocol, then you are SOL the moment someone finds out the details. That wouldn't necessarily mean you told them, either; they could have reverse-engineered without your knowledge, or been told by someone who knew (there wouldn't necessarily be any specific way of tracing the leak, either).
Obviously, secrets are in fact required for security, but that secrecy should be concentratd in well-defined and controllable things like encryption keys that individual people are responsible for.
Think about any multiuser OS in a secure configuration (I'll use a secured Unix as an example here) -- is the system secure because the users don't know how it works, or because it really is secure?
Relying on the obscurity of your protocol for security is like giving the root password to all of your users, and then trying to keep them from learning any more about Unix so they won't know enough to do anything malicious.
What you want to do instead is give them individual accounts, with individual passwords (secrets) and individual accountability, with access controls in place to prevent them from doing anything malicious. It's hard work, but protocols can be designed this way.
"Security Through Obscurity" doesn't really help; it just hides the problem from everyone but the people who have found a way to exploit it until it's too late.
Look at the situation with cheating and the Open Sourced Quake -- there have been the same kind of cheats (aimbots, b0rked models, modified rendering and so forth) long before Quake was open-sourced. The only substantial effect Open-Sourcing had in the case of Quake was making the people who weren't already cheating aware of the specific problems, and the exploits marginally more accessible.
Don't just take this from me, I would strongly encourage you to read books like "Applied Cryptography" by Bruce Schnier to get a better understanding of these issues.
Slashdot Mirror
Unfortunately, the moment that Slashdot directly or indirectly removes a post due to content, Slashdot becomes responsible, both in conventional and legal terms, for all user-submitted content on the site.
This is one of the primary reasons that the Slashdot editors have refused to remove posts in the past -- to do it voluntarily once (for any reason) means that they would be legally obligated to do so in the future (for any reason).
I think it's also important to draw a distinction between legality and ethics here: what Microsoft has done is to effectively apropriate an academically developed public standard, developed in large part with public funds. Think about that a second. Is that very ethical?
Ironically, due to the current state of law, what Microsoft has done is legal, and the public really has no direct legal recourse (the DOJ trial doesn't count, you can't add new charges after the verdict). Under these circumstances, while Slashdot readers posting the specification is unquestionably illegal, I have a very hard time convincing myself it was unethical.
In the long view, I think that this is (deliberately or not) about changing unethical laws, not just challenging unethical practices.
I just hope that the people posting the specifications really understand what civil disobedience is about -- they can be tracked down, and they should fully expect to be punished for breaking the law. As I understand it, under the DMCA, their circumvention of a copy-protection measure for any reason is a felony.
If you're not giving out the modifications in source or binary form, you're fine.
You'd only be in violation of the GPL if you were distributing your modifications and refused to make source availible.
It would seem that what the WinGate proxy does is to simply redirect all UDP traffic to ALL hosts on the network -- at least the local subnet ... the shotgun approach basically. The theory being that the ones that don't care about the data won't be listening, and won't see it.
They normally don't.
Consequently, it may be possible to tell ipchains to MASQ UDP packets to the network broadcast address, meaning that all the machines on the subnet will get them.
As long as you don't do this for any important ports (DNS, et al), you should be OK. Although the security guru in me is still screaming bloody murder.
But anyway...
That should at least allow you to access/stat files/subdirectories. Of course, if you don't have at least search on the subdirs and read on the file, you're still screwed.
... or is that netscape6 the one inside blind? ... in that case, I guess we're both right.
Nope, existing copyright law does just fine. Except for BSD or X licenses (where the point is actually that companies like MS _can_ use the code if they want), incorporation into a closed-source product would be in violation of the terms of the license.
As for proving that they've taken code, that's no easier to prove than for closed-source software, where your competitor may have managed to appropriate your source code through industrial espionage, or just snagging what had been a legal copy of the code floating around. You'd be suprised at how freely even the source code to Windows NT flows, especially at some educational institutions.
You obviously haven't spent very much time using proprietary Unices. For example, HP-UX's sed(1) doesn't seem to have been significantly updated since about 1983. Beleagured sysadmins like myself usually just say "fuck this" and install the GNU tools.
The gmake dependencies are there, but only with automake, not autoconf by itself. Really, gmake dependencies are the only real problem that I've ever encountered out of your list.
I honestly haven't had any problems with GNU shell scripts on any systems with a POSIX-compliant shell. (There are some Unices still floating around with a /bin/sh that is not fully POSIX-compliant). You're more likely to get bitten by differences in the supporting tools.
People who write shell scripts on GNU platforms do get sloppy with portability, yes, but that's not specific to GNU platforms.
Whoa whoa whoa... now that's just patently false. I mean, just consider the fact that the GNU tools ship for a large number of platforms without the GNU library (e.g. FreeBSD, Win32, even VMS ... eep!).
Even that aside, I've personally built and installed the vast majority of the GNU tools on a stock HP-UX 10.20 system. Everything seems to work fine, and the only caveat was that I needed to build and install GNU make first to build some packages that used automake.
So, no offense, but at least based on my own experience, I'd have to say that the claim that GNU tools are all dependent on the GNU C library is complete bullshit.
FreeBSD isn't a distribution of the GNU system, it's an entirely different system that happens to come with GNU tools extra.
/sbin/init.
If you removed all the GNU tools from a stock FreeBSD installation, it would still boot and basically everything would work.
All current Linux distributions are GNU systems, however. The core system around the kernel is all GNU software.
Remove all the GNU tools and libraries from a stock Linux system, and you'll be lucky if you can get as far as a single-user shell, let alone
Now, Tom Christianson (the Perl guy) had the idea a while back of creating a GNU distribution, but using the FreeBSD kernel. That would be a GNU system, and for that particular system, the GNU/FreeBSD moniker would be appropriate (although I doubt that was his intent).
Alternatively, if you replaced the GNU tools of a Linux distribution with the FreeBSD tools and libraries (after making appropriate changes to accomodate the kernel differences), you'd have something that you could justifiably call FreeBSD/Linux (that would be a much more constructive use of Tom's time, I think).
See how it works?
1. Iridium just happens to transmit on a radio band that radio telescopes listen to. Whoops.
2. The satelites are low enough, and have such a profile that sunlight reflecting off of them (even when it's night on the surface, the satelites are still out far enough that they may not be in Earth's shadow) can create bright flashes that can damage or destroy (expensive!) sensitive telescope optics.
The latter is a problem with other satelites too (to a small extent), but Iridium is by far the most severe.
...what they're getting into. (assuming for the moment that they're legit)
I kind of resent their abuse of the term "open source", too.
It's not as if you can just buy the birds so the old owners won't crash them. There's a lot of maintainence work that has to go on... continuously...
You then have to deal with them when they break (either write the affected satelite off, or see if you can engineer a workaround from the ground).
You have to keep them out of trouble.
You have to turn and shut them down at critical moments so the delicate bits won't get fried by solar flares, hit by flying bits of space junk (which you have to track relative to your birds and figure out if you need to worry about a particular item), or damaged by any other number of interesting astronomical "events".
You have to nudge them back into their orbits periodically to keep them from reentering and burning up early, screwing up other satelites, and just generally not being where they need to be to do their job.
It's a lot like taking care of a herd of 66 insanely expensive flying metal sheep, really. Remotely.
Ever since they've been launched, the Iridium satelites have been royally fucking up earth-based astronomy, too.
So, it's a lot like having a huge herd of 66 insanely expensive flying metal sheep that poop on everyone's lawn, so everyone hates them.
Oh, and they're in a low-earth orbit, too, which means their orbit isn't going to last that much longer anyway (five, ten years? ...the original plan was to keep launching satelites as the old ones expired... I don't think these "saveIridum" folks are prepared to do that). I hope these "open source Iridium" people (I really dislike their abuse of the moniker) are capable of deorbiting them safely, and in a controlled fashion, when the time does come.
(and when they come down they very likely might come down over major population centers if you don't know what you're doing ... the current owners at least know what they are doing)
(although I should note for the sake of the /. alarmists, that they'd probably just burn up in the atmosphere ... you still don't want to take those kind of chances, though!)
So, really, it's a lot like having no experience, buying a herd of 66 insanely expensive flying metal sheep that everyone hates because they poop on their lawn, and which are going to die soon anyway ... with the potential of severe (but spectacular) property damage ... and then calling it "open source".
Fortunately, looking at their page, it looks like they have about as many financial backers as they do clues... so, in conclusion, I'm very thankful that this "open source Iridium" thing is unlikely to succeed, if nothing else for the sake of the "open source" reputation.
What about tunneling X over ssh?
Really?
Only if you consider marshalling/unmarshalling individual drawing primitives across some sort of IPC (network or local) efficient. No, I'm not advocating direct application hardware access. Think outside the box, and maybe go back and look at how systems like NeWS, Display Postscript and Berlin are designed.
No, not really. Try writing a window manager sometime. The original idea was (is) pretty simple, but once you start adding the various standard extensions that accumulated over the years, if you're writing something major, it's a real mind-bending mess. You're fortunate nowadays that GTK+ and Qt hide a lot of the evil from you.
No argument there; X is tried, true, and it works.
That doesn't help you if you're remote ... and yes those are nice sometimes if you're remote.
Ever wonder why that hasn't been done yet? It's because most people who thought about it decided it wasn't worth the trouble: existing applications might run, but they wouldn't get the new functionality (i.e. antialiased characters). They would still still require a rewrite (yes, a rewrite, not just recompiling). The APIs and necessary backend code are just necessarily that different, because the original X ones were designed so badly.
[To be fair, the situation is a little better now, just because modern toolkits abstract the stuff enough that you could get by with only minor changes to the library APIs ... in most cases you'd just have to recompile the apps that didn't use the changed APIs, and only make minor changes to the ones that did, or that bypassed the library in some way]
If the antialiased font server was backwards compatible, it would only be because it kept the entire old (now redundant) architecture and API, in addition to implementing the new one.
The necessity of taking this approach to extend other aspects of X is one of the contributing factors to its bloat over the years.
Agreed, for the most part. However, arbitrated (i.e. not totally unsupervised) hardware access is still good for certain classes of specialized applications, and of course games. That's the need that ultimately spawned fbcon and KGI (the GGI kernel layer).
Something to ponder in parting... if someone wants to experiment with a windowing system that is not X, they either need to rewrite all the drivers themselves, run under X (...then what's the point?) or they need to have some kind of non-X driver infrastructure availible.
i.e. has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix?
Note: IANAL. Do not consider this legal advice.
Yes. Patches in excess of 10 LOC are copyrightable (and thus under current law implicitly copyrighted) material. (the 10 LOC is a matter of legal precedent)
Yes. See above
... nothing ... I don't see the problem there.
I believe you misunderstand the nature of GPL "infection". What you end up with is a compound work carrying the copyrights (and respective licenses) of _both_ copyright holders, each retaining copyright on the portions of the work they contributed. No license is changed.
If the licenses are compatible (e.g. not contradictory -- this is the case with LAME and the ISO encoder), you're fine. If not, you just have a compound work that is illegal to distribute.
Under copyright law, you have no rights to do anything with a copyrighted work except those explicitly granted you by the copyright holder(s) through licensing, and those rights granted you by law and legal precedent (i.e. fair use).
Therefore, if the "compound license" is "impossible" (self-contradictory), then you have no license, and thus no legal right to redistribute the compound work.
It is certainly possible and legal to make a patch for the Linux kernel under a proprietary license, but it would still be illegal to distribute a Linux kernel (in source or binary form) with the patch applied, without prior permission from the copyright holders of the Linux kernel (which in practical terms would mean you being given a copy with a license other than GPL to have your way with).
Soft realtime (the announcement in the article regards hard realtime; see other comments for the distiction) generally does good enough. I'm in the habit of running my X server and window manager with realtime priority on slower machines (when I'm not doing anything else compute-intensive that I care about). It does make a big difference in that regard -- where the problem actually is CPU contention, anyway...
So, it's not a matter of starting over, just a matter of selecting another one of the existing Linux schedulers. (this operation is NOT, I repeat NOT synonymous with nice(2) -- see sched_setscheduler(2) and friends)
I actually wrote a set of tools that allow you to manipulate the realtime schedulers under Linux (soft realtime was introduced in Linux 1.3.something, if I remember correctly), and they're on freshmeat as rt-utils.
The homepage, and download links are out-of-date, but I'll get around to dealing with that soon. In the meantime, if you want a copy, drop a line to mental@rydia.net
CSS allows you to specify all of the font styles for the elements of the document in ONE place. Want your H1s to be in "BastardWeird"?
... this once, at the top of the file (the HTML comments are optional -- just there to prevent the CSS code from showing up in non-CSS browsers), instead of having:
... around every single H1 in the document. That's a savings of about 39 bytes PER H1, after an initial cost of about 70 bytes. Maybe H1 is a bad example (it doesn't get used more than once or twice in a document usually), but this extends to other tags too, and not just to fonts. CSS also replaces FONT COLOR and a lot of other things that before needed to be coded multiple times into the same HTML document.
This is an even bigger win when you use a single, central css file (referenced via LINK REL=stylesheet), rather than coding CSS into every document. Maintainence also magically becomes easier. Want to change your whole site's look? Edit one file.
The only reason Open Source works is that everybody donates their time, and do something else to eat. If everybody got paid for what they did, all the software would be better, but how are you going to pay everybody.
I've been paid to work on open source software -- but, I wasn't been paid for the software I wrote, I was paid for the work I did. Most programmers are paid like that anyway -- what percentage of programmers of closed-sources software do you know who get per-copy royalties? (the answer: very few. even the ones who freelance are typically paid by the hour, not per copy of software used)
I don't think charging consumers per-copy is really fair, given that the programmers typically never get any of it anyway. We may as well stop trying to pretend programming isn't a service, and focus on funding software development appropriately.
I dunno, probably interferometry techniques applied to diffuse reflection. Unlikely to ever be as accurate as in the movie, however. (accuraccy in "unseen" regions would also degrade exponentially with distance)
Probably be a matter of iteratively refining a volumetric model from initial heuristic "guesses", I suppose. Most wrong guesses would be detectable as the results would visibly lose self-consistency after the first few iterations.
(also a good way to detect doctored images, although I daresay there are easier and more efficient ways of detecting those)
although even a line of original GPL code is enough to keep it under the GPL
Actually I believe the legal precedent is that that about 10 LOC is about the limit for copyright protection (regardless of license).
This guy's entire argument seems to be based on
the (false) assumption that corporations are
not legally bound by contracts/licences as
individuals are.
In actuality, the very PURPOSE of incorporation is to create a new legal entity (sort of a fake person) that can take legal responsibility for its own actions, rather than the company's head being explicitly liable.
To put this another way: if corporations weren't bound by licenses as individuals are, why do they even bother to license software (under any license, even proprietary licenses) from each other? Why do CORPORATIONS put their copyright on code they produce, rather than the individual programmers working for them?
This supposed "hole" is bogus.
So if Microsoft suddenly enforced this law in the US, and by accident one of the disabling emails went to a user in the UK, then Bill Gates or Ballmer would get an extradition notice because they are ultimately liable for Microsofts software.
No, they're not personally liable. Liability is held by the incorporated legal entity "Microsoft". That's one of the functions of incorporation, in fact -- a corporation becomes its own legal "person", accountable for its own actions, independent of any of its members. More or less.
Because the length of copyright protection has been continuously extended, almost nothing's gone into the public domain since World War II.
Copyright protection is now for such a long period of time that the "limited monopoly for long enough to compensate the author/artist, then let it become public domain to encourage the advancement of the arts" model is completely broken.
This would be a bad thing? Why?
So you are saying, that we are getting often files slower than we could on the same connection for some rason that is in stack? Then we gotto remove that stupid limit NOW. I want my modem work at it's fullest.
Then the Internet collapses as all the major backbones get saturated, and the world as we know it ends. Tragedy of the Commons, my friend.
A friend of mine who does GBC development told me that Nintendo (like most console/handheld makers) makes money by selling their stations/handhelds at a loss, and making up for it by the licensing fees they charge developers. Consequently, they have a pattern of working hard to crush the "hobbyist" development community, since hobbyists don't generally pay licensing fees. As if Nintendo really needed the additional money...
Wouldn't an open source credit card verification system be a Bad Thing(tm)? I would assume that this would make it easier to engineer the ablility to compromise the transaction. I know that security through obscurity is a bad policy by nature, but in these types of things, is it not required?
Not really, no. Well-designed secure protocols retain their security even when all of the participants know all the details of the protocol, and even when one or more of the participants is malicious.
If it makes a difference whether or not people know the full protocol, then it's a sign that the protocol isn't really secure in the first place. It's a sign that you already have a problem.
If you're relying on secrecy of the protocol to protect the integrity of the protocol, then you are SOL the moment someone finds out the details. That wouldn't necessarily mean you told them, either; they could have reverse-engineered without your knowledge, or been told by someone who knew (there wouldn't necessarily be any specific way of tracing the leak, either).
Obviously, secrets are in fact required for security, but that secrecy should be concentratd in well-defined and controllable things like encryption keys that individual people are responsible for.
Think about any multiuser OS in a secure configuration (I'll use a secured Unix as an example here) -- is the system secure because the users don't know how it works, or because it really is secure?
Relying on the obscurity of your protocol for security is like giving the root password to all of your users, and then trying to keep them from learning any more about Unix so they won't know enough to do anything malicious.
What you want to do instead is give them individual accounts, with individual passwords (secrets) and individual accountability, with access controls in place to prevent them from doing anything malicious. It's hard work, but protocols can be designed this way.
"Security Through Obscurity" doesn't really help; it just hides the problem from everyone but the people who have found a way to exploit it until it's too late.
Look at the situation with cheating and the Open Sourced Quake -- there have been the same kind of cheats (aimbots, b0rked models, modified rendering and so forth) long before Quake was open-sourced. The only substantial effect Open-Sourcing had in the case of Quake was making the people who weren't already cheating aware of the specific problems, and the exploits marginally more accessible.
Don't just take this from me, I would strongly encourage you to read books like "Applied Cryptography" by Bruce Schnier to get a better understanding of these issues.