About the addition: I didn't mean whether or not to integrate with the Debian project, rather than to whether integrate with the systems it currently produces--the unstable, testing, stable distributions of GNU (/Linux and/Hurd).
I can also understand why, in the case of handguns, in many countries the technology to commit the crime is regulated instead of just the crime itself; a single misaimed gunshot causes irrepairable damage to human life. They are extremely dangerous devices, so I can see why a democratic government would choose to regulate trafficking of guns, even before any crime has been committed with them.
Copying on the other hand causes no damage by itself, regardless of what's being copied. Only *distribution* of copied things causes *economic* damage. So why a democratic government would want to prohibit a means (unrestricted digital technology) to a prerequisite (copying data) to the actual *economic* crime (mass-distributing copies), while it does not want to regulate guns, based on the argument 'we only go after the crime itself', is completely, totally, utterly beyond me.
Unless, of course, this 'democratic' government cares more for money than for human life. It sure is telling about its priorities, in any case.
What Bill or anyone else *likes* to do or to get is not an argument in evaluating the rights and wrongs of such issues.
If business models such as this are only possible by having people rent the boxes instead of *own* them, then that should be done instead of leading people to believe they have *bought* something.
After all, the US regards ownership of property as the highest goal for humanity? It does make you wonder though who's in charge if the latest laws are more concerned about ownership by some cartels than ownership by the people.
Not to fork makes enormous sense. A 'Debian based' distribution is a hollow phrase to begin with, if it must do without the procedural, human and technical infrastructure of the Debian project. Debian's strength isn't apt-get, it's debian-policy, combined with a package system that's powerful enough to express the relevant parts of that policy.
Debian as a process has proven itself to scale quite well, considering the number of packages, the number of upstream authors, the number of package maintainers and the low number of bugs.
It seems a very good idea to re-use the model for other large free software projects with a high number of discrete components. Whether such projects should be integrated into the distributions currently produced by the Debian project or if they should be defined as separate 'products' may be another issue, but I'd say that if the product is an unix-like OS that uses the Linux kernel, integrating seems the obvious choice.
True. That's what I use as well. However, in a lot of cases the move from the frontends to editing the configuration directly will be a one-way one. Most frontends are too stupid to provide correct r/w support to the data they manage. Their internal representation is king, and they merely 'export' that to the config files they manage. IOW, the management tool contains less reading intelligence than the application it manages.
In short, if you use vi on/etc/*, the management tools' internal configuration DBs will get out of sync. You may be able to fix a config problem, but it creates a mess for the hapless user who likes to use his friendly tools again after you're done.
Of course, some configuration files are more like scripts and those will always be hard to read and represent by graphical tools, while those tools will still be easily able to generate script templates. I guess the distinction between a 'template generation tool' and an actual 'configuration management tool' should be presented more clearly, with the latter label being only applicable to *true* r/w tools, that can read all files that would be also considered valid by the actual application.
For the latter, config files resembling scripts are out, but config files that are essentially trees of attribute/value pairs should be no problem.
(It would be nice btw if the filesystem would offer a way of managing them properly by efficiently handling lots of small files. Then we can have a uniform representation of those config trees without going down the slippery slope of the filesystem-in-filesystem nonsense offered by the windows registry. open, read, write, close are good enough -- why would you need a separate reg_put_key and reg_get_key and so on?)
Hm, a nicer UI, eh? Looking at http://ibiblio.org/pub/Linux/distributions/contrib/texstar/screenshots/redhat80/snapshot03.jpg, we have
- preferences, *and* - server settings, *and* - system tools, *and* - system settings, *and* - control center, *and* - configure panel.
And you think it should be immediately obvious from these items, that appear in a completely unsorted and ungrouped menu, what they mean and what the distinction is? I must admit the theme looks surprisingly friendly (if not soft), but seriously, this is painful, if not patently absurd.
Is it really necessary to make a difference between Preferences, System Settings, and a Control Center? Between System Settings and Server Settings? And is there any reason why all these should live outside the Control Center? Is there any reason at all to have a Control/Center/ if all the knobs and tweaks are already available elsewhere?
Make up your mind I'd say. If you *desparately* want to supply more than one configuration item, reduce it to 'Personal Preferences' and 'System Settings', a distinction which at least has some meaning for people who already know that different people can use the computer each in their own way, but that some people may control the computer's overall behaviour as well.
The mixing of verbs and nouns in the same list is also horribly confusing. The submenus should get their own group and the rest should be *verbs*, if you want to give the user any feel of predictability at all (*Launch* Control Center. *Get* Help. *Open* Home folder). Or go the other way, with an implicit Start, Launch or Open everywhere, but then please be consistent and call 'Find Files' the 'Search Tool'.
Come on guys, I'm also a C programmer instead of a UI designer, but is it really so hard to avoid making a mess? No wonder even geeks are switching to Macs these days.
Tell me, how is it easier for a library routine to check its arguments than it is for a program to check its command line?
There is *less* of a security boundary between an application and a library than between two applications, not more. Programs can only talk to programs using argv[], envp[] and pipes -- well-defined interfaces enforced by the OS, while talking to libraries can be done using any random ad-hoc set of function calls and global variables. Also, a library can never shield its own data structures; it shares its heap with the application.
There's only a parsing issue if the actual email application can't handle gpg's textual output and barfs; gpg itself already has to consider its input untrusted anyway. But gpg's private data won't be exposed in either case.
Perhaps gpg could use a more computer-readable output format, but that's all. I think data-based interfaces as opposed to library calls are *good*. The less language binding the better. Less chance of pointer errors or code slowly turning into callback spaghetti that way.
Oh, and you saying that fork(), dup() and exec() are fundamentally hard tells me that I wouldn't trust you with a gpg.so.1 either. Sorry.
Cringely's may be right in his suggestion that we may need mass protests in order to get rid of a totally absurd law that tilts the balance of power between producer and consumer completely in favour of the former. But if you think about it, it's also quite alarming that mass protests are needed to remind the government to work in the public interest and to consider one of the most important principles of democracy--freedom of communication--before writing a law.
A democracy should be a government of the people, by the people, for the people, as Lincoln put it. The US have gone quite a long way since then. It has gotten a government of the people, by the industry, for the economy.
Of course, the economy is very important. The primary needs of people are food and shelter. If those can be most efficiently provided by a healthy economy, and if a healthy economy can best be established by private companies that only need to act in the monetary interests of their shareholders, then humanity has found a nice trick to profit from greed instead of suffering from it, and it can be said that it is indeed in the best interest of the people to create a legal system that supports those institutions of canalized greed.
But greed in itself only respects the law of the jungle, and does not value democracy's principle of every citizen's vote being equally important. Instead of 'one man, one vote', private enterprise works according to the principle of 'one dollar, one vote', and where the dollar comes from, it really matters not.
Therefore, a democracy cannot work by allowing the economy's fuel, greed, to flow unchecked, because the even distribution of power among all people would merely become an even distribution of power among all people of equal wealth. And if democracy does not choose to distribute wealth evenly, its only other choice is to minimize the power of the wealthy over the poor.
To stay a democracy, I think that a government must at least respect these two laws: 1. guard the freedom and the vote of all citizens against the concentrations of (economic) power in society, and 2. serve the (economic) interests of the people, but only where that doesn't conflict with the first law.
The ordering principles of the economy do not lead toward democracy, they lead away from it. Democracy and economy can co-exist, but only if the former is in charge. It kills itself if the economy becomes more than means to an end.
The USA is definitely heading away from democracy, and it's not hard to see why. People who haven't heard from you won't vote for you. Reaching people through mass media costs money, even for politicians, so the politicians with the most money can reach the most people. In the US, that money may come from donations by private entities, making politicians susceptible to the obligations that tend to come with gifts. Of course, the bigger the gifts, the bigger the obligations.
Therefore, the system already leans towards 'one dollar, one vote', instead of actively working against it, as a democracy should, in order to maintain itself. Every law that favours existing economic interests at the cost of the freedom of the individual citizen is evidence of that. We know the DMCA and the CBDTPA as particularly painful examples, but they may not be the only ones.
The only way to defend our freedom is to fight for real democracy, the 'one man, one vote' type, and against its perverted brother, the 'one dollar, one vote' type. We can only do that only if we take every step necessary to remove the influence of money from the government.
Power alone already corrupts enough. Let's not add money to it!
Offtopic, but... Do you find yourself able to really/concentrate/ with music playing in your ears? I can do some paperwork, read mail, and toy around with something, but when I'm developing I need silence, with nothing but klicking of my keyboard and the sadly inevitable whirr of a harddisk to break it.
(By the way, does MSFT really make you add a disclaimer to your slashdot posts? It looks pretty silly. Of course nobody's going to think that you're the official voice representing MS' views. Don't give in so easily to the corporate lawyers' idea of what the world should look like, unless you want to help them establish that world).
Hm, yes, but what if DivX disks would have cost, say, 1/2 the price of the original DVDs? The industry would have had to invest a few years, and when everybody's converted, they could have turned the thumbscrews. They just didn't invest enough for DivX to work.
The 'vote with your wallet' concept is flawed. People tend not to be able to correct the short term lower price for long term bad effects. Companies with an agenda to push and who can bear it a while financially can definitely buy your vote that way.
That's why a purely darwinistic capitalistic system, without a deeply entrenched system to protect the individual's rights against the wishes of the most powerful group, economically or otherwise, will eventually degrade into A Brave New World.
Just as the public protects its members, by law, from selling themselves as slaves, should it protect its members from selling their ability to communicate freely in a digital environment to the corporatii.
DRM turns your computer into a read-only device. It takes away your ability to share and communicate digital information freely. The Content Cartel wants to be able to tell you a secret without you being/able/ to tell it to anybody else. This has never been possible in the analog world (without resorting to drastic meastures), but it looks like they are succeeding in the digital world. Our digital communications will be governed 100% by the 100% short term, 100% economic interests of the Content & Distribution Cartel.
... that was up on slashdot a while ago. It allowed you to send messages that scrolled by on a 18x8 screen made of lamps in office rooms and play Pong on your GSM (see http://www.blinkenlights.de/).
It's not even that original, considering the fact that (at least here in NL) a lot of clip stations are continuously scrolling by SMS messages from random people. Everyone his 5 seconds of fame. Hmm.
The laser would be a fun way to ask a geeky other half to marry though.
On the otherhand, software has NEVER been broadcast over public airwaves
Why, it has! Here in the Netherlands in the 80's, you had the NOS Hobbyscoop, a radio programme on public radio that broadcast home computer software. It used a standard for compatible BASIC programs, called BASICODE. It was basically a 'shared library' with well-known subroutines at well-known line numbers.
You'd record the part with the awful sounds on your cassette recorder, and then you could load it onto your Spectrum or C64 or MSX. Loads of fun!
The thing is, I think that software projects should be more viewed as the individual members of a population than the species as a whole. I.e. there's lots of parallel development, and relatively little change within each individual project.
A member can develop a feature (gene), but it does not get to other members (projects) until they are replaced by a new generation of offspring. Luckily a new version is sometimes enough, but often a new generation (rewrite or a completely new project) *is* what's needed to adopt revolutionary features developed elsewhere.
Of course you're completely right that this is nonsense when it comes to trivial things like resolution changers. But it's also natural that projects don't just copy *implementations* of trivial features if their maintainers think that those are badly done or don't fit their standards in other ways.
I thought one of the benefits to the GPL was code Darwinism?
Oh, and you thought that when an individual of an evolving species picked up a nice feature, all the other members instantaneously picked it up as well and implemented it in exactly the same way? You think evolution happened in a straight line?
I think what you're seeing is very healthy behaviour. Everyone thinks that he can do slightly better than the other guy who has already done it. Of course, only 5 % will be right in that assessment, but who cares as long as in the end it does improve the state of the art.
People should be cautious not to suffer too much from a 'not invented here' syndrome, but reinventing the weel once in a while isn't bad at all if that makes a better mousetrap.
They are, but somehow I don't believe that anybody uses those for day to day work, or even play. I couldn't help thinking "what's the use, other than the visual experience that you'll be able to endure about 5 minutes". It's nice as an artwork example, but completely useless as an example of a well designed GUI.
will the next generation of PCs be able to run user-built software, and use that to
publish content on the internet?
Because I think that's what the cartels are eventually after: the people's very ability to communicate freely, privately, in a digital environment.
Why? Because what they effectively want is to be able to give someone a secret (i.e. a music track), while getting a guarantee that that person won't give the secret to anybody else.
In analogue space, it's obvious that getting such a guarantee is not possible without pulling the person's tongue out and/or cutting his hands, if you want to *guarantee*, beforehand, that he won't leak the information.
For some reason, in digital space people don't seem to object as much to converting their PCs to read-only devices, reducing the internet to clickable TV, and reducing freedom of digital expression to mere freedom of digital consumption.
The governments thinks it's fine too, because they think that they can provide more safety that way, because they are primarily appointed to take care of the economic status quo, and because creating a healthy environment for corporate power play is more important than to create a healthy environment for human creativity anyway.
It's a damn shame, but it seems this all happens because people are happy enough being mere consumers. This can go much further, see Huxley.
Society should fear when it encourages such behaviour though, instead of fighting it.
The problem is that some programmers tend to forget that to design is all about making choices. As that is a difficult activity, people tend to just 'make it a config option' and forget about the issue.
But people, configurability is good, but *putting the burden of 90% of UI design on the shoulders of the poor user* is not.
Indeed, because everybody effectively creates his own destkop environment because so little attention has been given to the *actual, practical, day-to-day, real-world* usability of the defaults, no effective feedback is provided to UI developers. The few advances in the field that are made are way too fragmented. This is a terrible waste.
We should strive to be able to build a *good, beautiful* UI. Not to demo the latest alpha blending feature, if it's ugly and confusing as hell. We should lean from Fitt's law, from people like Jeff Raskin, from Windows and MacOS 9, from OS X and X Windows and from people's gripes about all of those.
And, let's learn from Unix. We should build this UI using/Unix/ technology (that is pipes, sockets, processes, read, write, select, ioctl, mmap), and not with Corba, our COM-like thingy of the day or other funky fat binary interfaces, and not with multithreaded dlls that do not want to choose whether they are a process or a library. Let's not reinvent the OS in a very crappy and un-unixy way merely because we're building a GUI, for chrissakes. I really don't think the requirements of GUIs are so unique that that's needed. A module interface that allows each and every method in each and every every object to call each and every method in each and every other object in the system does not give any modularity, sorry. Think again. That's old-fashioned linking, worse, effectively going back to the days of single address space OSes by linking every application to every other, and that doesn't get you anywhere if you want to make standard, stable, secure component interfaces.
You don't want to have 'more' to have a funky ad-hoc RPC interface so that it can be called by 'ls', or do you? We may need to extend the pipe concept if it's to limited for GUI app-to-app interfaces, but let's do that then, without resorting to plain, unrestricted RPC all the way. Please.
Let's keep it simple, and let's make it beautiful.
The thing is, you can *request* anything, even for someone to keep a secret. But you're simply unable to *force* someone to keep a secret, with zero risk that it will leak, unless you exercise some drastic methods of aforementioned type (maim or isolate the person). But it's exactly that kind of methods that the content cartel want to impose on us, only in a digital sense. It demands from society that it applies that kind of methods to its citizens. And sadly, society thinks the short term economical benefits (money in campaign warchest! Cheap DVDs! Jobs provided by the RIAA members! Great!) are worth it.
The free-riding problem *cannot be solved* with digital information.
Companies only have their distribution mechanisms for digital information to compete with. If a CD distributor doesn't perform as well in the bandwith*convenience/price arena as your local ISP/telco, then it's a matter of *tough luck*, at least in a free market.
Oh, you want to publish something to some but keep it secret to others who haven't paid? You want to tell someone a secret but you want to guarantee, beforehand, that he cannot possibly tell another? *Tough luck*, unless you tell the secret and then rip out the other person's tongue and chop off his hands prevent him from further communicating with anybody else. The only way to make that happen digitally is to make every PC a read-only device. Oh, that's what you want then? But we already have that, you dumbf'ck, it's called TV. We don't want TV. We're sick of TV, and we won't allow our computers to be replaced by TVs just because some industry paid f'ck said so. Get over it.
RIAA, MPAA: the game is *over*. Cope. Please take your whining elsewhere, and please stop abusing society by buying f'cking laws.
When no good music gets recorded, no good books get written, no good movies get produced and no good paintings are being made anymore because the artists are starving, I'm sure society can come up with a *better* solution than simply handcuffing all its inhabitants, don't you think?
I'd say if you want to publish something digitally, you'll just have to live with the initial payment. If that's not enough, convince more people to pay before publishing it. If not enough people want to do so, then *tough luck*. If they do, all the better. It's still a free market after all, only one where the public is a *single* customer. If that customer wants to buy something valuable, he may have to make some savings up front. The concept is not even new, it already works fine for public highways. Society wants them, because society as a whole benefits from them, so society decides to pay for them as a whole. What's so f'cking hard about that?
Actually, x86's architecture for call gates and segment descriptors isn't that bad. To some extent, they are always needed; even the Linux kernel (which uses only paging, no segmentation) has to supply correct code, data and stack segment descriptors, and has provide interrupt gates (very similar to call gates) for the syscall and hardware interrupts.
The only drawbacks is that you have only four rings and that it's non-portable as hell. But it's very well documented, and works, too.
A setuid program is the exact software equivalent of a call gate, BTW. You need a certain privilege level to use the call gate, and after that, the routine uses the (possibly higher) privilege level set by the call gate. Exactly the same as having a setuid program that's executable only by a certain group. It's a very common (and useful) concept in both hard- and software.
There's nothing fundamentally wrong with the concept of setuid programs on Unix; you use them to check untrusted input before submitting it to higher privileged programs that need to trust it. The problem is that a lot of setuid programs don't do their job of checking input properly, or worse, don't treat environment variables as untrusted input as well.
(Aside: I've sometimes thought that Unix' way to connect applications to devices (read/write, seek, ioctl, that's it) is still so successful because it mimicks the way a CPU is connected to periferial devices in hardware: a data bus, an address bus and a few out-of-band control lines.)
From the introduction of the new paper: "However, the bottom line conclusion was that 'restructuring is essential' around a verifiable 'security kernel' before using Multics (or any other system) in an open environment (as in today's internet)".
Paragraph 3: "We hypothesised that professional penetrators would find that distribution of malicious software would prove to be the attack of choice."
Dropped in as a random sentence in paragraph 5, without much relation to the surrounding text: "Multics source code was readable by any user on the MIT site, much as source code for open source systems is generally available today."
From the conclusion of the new paper: "In nearly thirty years since the report, it has been demonstrated that the technology direction that was speculative at the time can actually be implemented and provides an effective solution to the problem of malicious software employed by well-motivated professionals. [...] And customers have said they have never been offered mainstream commercial products that give them such a choice, so they are left with several ineffective solutions [...]".
If you look at what is actually being demonstrated in the original paper, is that a monitor is needed that governs every memory access, without bypasses. The new paper admits that the VAX was the first to have this, and of course all modern MMUs do exactly that.
So what's the big deal? Why was this published at this time? If you read carefully, you can correctly conclude that we don't need no steenkin' Palladium to get secure systems today; we already have all the hardware features needed. However, if you skim the new paper, you could be led to believe that Palladium is absolutely essential...
Slashdot Mirror
I've never seen a commercial company run a similar service using Linux.
Google?
About the addition: I didn't mean whether or not to integrate with the Debian project, rather than to whether integrate with the systems it currently produces--the unstable, testing, stable distributions of GNU (/Linux and /Hurd).
I can also understand why, in the case of handguns, in many countries the technology to commit the crime is regulated instead of just the crime itself; a single misaimed gunshot causes irrepairable damage to human life. They are extremely dangerous devices, so I can see why a democratic government would choose to regulate trafficking of guns, even before any crime has been committed with them.
Copying on the other hand causes no damage by itself, regardless of what's being copied. Only *distribution* of copied things causes *economic* damage. So why a democratic government would want to prohibit a means (unrestricted digital technology) to a prerequisite (copying data) to the actual *economic* crime (mass-distributing copies), while it does not want to regulate guns, based on the argument 'we only go after the crime itself', is completely, totally, utterly beyond me.
Unless, of course, this 'democratic' government cares more for money than for human life. It sure is telling about its priorities, in any case.
What Bill or anyone else *likes* to do or to get is not an argument in evaluating the rights and wrongs of such issues.
If business models such as this are only possible by having people rent the boxes instead of *own* them, then that should be done instead of leading people to believe they have *bought* something.
After all, the US regards ownership of property as the highest goal for humanity? It does make you wonder though who's in charge if the latest laws are more concerned about ownership by some cartels than ownership by the people.
Not to fork makes enormous sense. A 'Debian based' distribution is a hollow phrase to begin with, if it must do without the procedural, human and technical infrastructure of the Debian project. Debian's strength isn't apt-get, it's debian-policy, combined with a package system that's powerful enough to express the relevant parts of that policy.
Debian as a process has proven itself to scale quite well, considering the number of packages, the number of upstream authors, the number of package maintainers and the low number of bugs.
It seems a very good idea to re-use the model for other large free software projects with a high number of discrete components. Whether such projects should be integrated into the distributions currently produced by the Debian project or if they should be defined as separate 'products' may be another issue, but I'd say that if the product is an unix-like OS that uses the Linux kernel, integrating seems the obvious choice.
IANADD, though (yet).
True. That's what I use as well. However, in a lot of cases the move from the frontends to editing the configuration directly will be a one-way one. Most frontends are too stupid to provide correct r/w support to the data they manage. Their internal representation is king, and they merely 'export' that to the config files they manage. IOW, the management tool contains less reading intelligence than the application it manages.
/etc/*, the management tools' internal configuration DBs will get out of sync. You may be able to fix a config problem, but it creates a mess for the hapless user who likes to use his friendly tools again after you're done.
In short, if you use vi on
Of course, some configuration files are more like scripts and those will always be hard to read and represent by graphical tools, while those tools will still be easily able to generate script templates. I guess the distinction between a 'template generation tool' and an actual 'configuration management tool' should be presented more clearly, with the latter label being only applicable to *true* r/w tools, that can read all files that would be also considered valid by the actual application.
For the latter, config files resembling scripts are out, but config files that are essentially trees of attribute/value pairs should be no problem.
(It would be nice btw if the filesystem would offer a way of managing them properly by efficiently handling lots of small files. Then we can have a uniform representation of those config trees without going down the slippery slope of the filesystem-in-filesystem nonsense offered by the windows registry. open, read, write, close are good enough -- why would you need a separate reg_put_key and reg_get_key and so on?)
Hm, a nicer UI, eh? Looking at http://ibiblio.org/pub/Linux/distributions/contrib /texstar/screenshots/redhat80/snapshot03.jpg, we have
/Center/ if all the knobs and tweaks are already available elsewhere?
- preferences, *and*
- server settings, *and*
- system tools, *and*
- system settings, *and*
- control center, *and*
- configure panel.
And you think it should be immediately obvious from these items, that appear in a completely unsorted and ungrouped menu, what they mean and what the distinction is? I must admit the theme looks surprisingly friendly (if not soft), but seriously, this is painful, if not patently absurd.
Is it really necessary to make a difference between Preferences, System Settings, and a Control Center? Between System Settings and Server Settings? And is there any reason why all these should live outside the Control Center? Is there any reason at all to have a Control
Make up your mind I'd say. If you *desparately* want to supply more than one configuration item, reduce it to 'Personal Preferences' and 'System Settings', a distinction which at least has some meaning for people who already know that different people can use the computer each in their own way, but that some people may control the computer's overall behaviour as well.
The mixing of verbs and nouns in the same list is also horribly confusing. The submenus should get their own group and the rest should be *verbs*, if you want to give the user any feel of predictability at all (*Launch* Control Center. *Get* Help. *Open* Home folder). Or go the other way, with an implicit Start, Launch or Open everywhere, but then please be consistent and call 'Find Files' the 'Search Tool'.
Come on guys, I'm also a C programmer instead of a UI designer, but is it really so hard to avoid making a mess? No wonder even geeks are switching to Macs these days.
Tell me, how is it easier for a library routine to check its arguments than it is for a program to check its command line?
There is *less* of a security boundary between an application and a library than between two applications, not more. Programs can only talk to programs using argv[], envp[] and pipes -- well-defined interfaces enforced by the OS, while talking to libraries can be done using any random ad-hoc set of function calls and global variables. Also, a library can never shield its own data structures; it shares its heap with the application.
There's only a parsing issue if the actual email application can't handle gpg's textual output and barfs; gpg itself already has to consider its input untrusted anyway. But gpg's private data won't be exposed in either case.
Perhaps gpg could use a more computer-readable output format, but that's all. I think data-based interfaces as opposed to library calls are *good*. The less language binding the better. Less chance of pointer errors or code slowly turning into callback spaghetti that way.
Oh, and you saying that fork(), dup() and exec() are fundamentally hard tells me that I wouldn't trust you with a gpg.so.1 either. Sorry.
Cringely's may be right in his suggestion that we may need mass protests in order to get rid of a totally absurd law that tilts the balance of power between producer and consumer completely in favour of the former. But if you think about it, it's also quite alarming that mass protests are needed to remind the government to work in the public interest and to consider one of the most important principles of democracy--freedom of communication--before writing a law.
A democracy should be a government of the people, by the people, for the people, as Lincoln put it. The US have gone quite a long way since then. It has gotten a government of the people, by the industry, for the economy.
Of course, the economy is very important. The primary needs of people are food and shelter. If those can be most efficiently provided by a healthy economy, and if a healthy economy can best be established by private companies that only need to act in the monetary interests of their shareholders, then humanity has found a nice trick to profit from greed instead of suffering from it, and it can be said that it is indeed in the best interest of the people to create a legal system that supports those institutions of canalized greed.
But greed in itself only respects the law of the jungle, and does not value democracy's principle of every citizen's vote being equally important. Instead of 'one man, one vote', private enterprise works according to the principle of 'one dollar, one vote', and where the dollar comes from, it really matters not.
Therefore, a democracy cannot work by allowing the economy's fuel, greed, to flow unchecked, because the even distribution of power among all people would merely become an even distribution of power among all people of equal wealth. And if democracy does not choose to distribute wealth evenly, its only other choice is to minimize the power of the wealthy over the poor.
To stay a democracy, I think that a government must at least respect these two laws: 1. guard the freedom and the vote of all citizens against the concentrations of (economic) power in society, and 2. serve the (economic) interests of the people, but only where that doesn't conflict with the first law.
The ordering principles of the economy do not lead toward democracy, they lead away from it. Democracy and economy can co-exist, but only if the former is in charge. It kills itself if the economy becomes more than means to an end.
The USA is definitely heading away from democracy, and it's not hard to see why. People who haven't heard from you won't vote for you. Reaching people through mass media costs money, even for politicians, so the politicians with the most money can reach the most people. In the US, that money may come from donations by private entities, making politicians susceptible to the obligations that tend to come with gifts. Of course, the bigger the gifts, the bigger the obligations.
Therefore, the system already leans towards 'one dollar, one vote', instead of actively working against it, as a democracy should, in order to maintain itself. Every law that favours existing economic interests at the cost of the freedom of the individual citizen is evidence of that. We know the DMCA and the CBDTPA as particularly painful examples, but they may not be the only ones.
The only way to defend our freedom is to fight for real democracy, the 'one man, one vote' type, and against its perverted brother, the 'one dollar, one vote' type. We can only do that only if we take every step necessary to remove the influence of money from the government.
Power alone already corrupts enough. Let's not add money to it!
Offtopic, but... Do you find yourself able to really /concentrate/ with music playing in your ears? I can do some paperwork, read mail, and toy around with something, but when I'm developing I need silence, with nothing but klicking of my keyboard and the sadly inevitable whirr of a harddisk to break it.
(By the way, does MSFT really make you add a disclaimer to your slashdot posts? It looks pretty silly. Of course nobody's going to think that you're the official voice representing MS' views. Don't give in so easily to the corporate lawyers' idea of what the world should look like, unless you want to help them establish that world).
And that's how to save the U.S. economy.
While destroying everything that has value other than monetary.
But the world is getting used to that U.S. concept. Slowly, but we're learning from this 'pinnacle of civilization'.
Hm, yes, but what if DivX disks would have cost, say, 1/2 the price of the original DVDs? The industry would have had to invest a few years, and when everybody's converted, they could have turned the thumbscrews. They just didn't invest enough for DivX to work.
/able/ to tell it to anybody else. This has never been possible in the analog world (without resorting to drastic meastures), but it looks like they are succeeding in the digital world. Our digital communications will be governed 100% by the 100% short term, 100% economic interests of the Content & Distribution Cartel.
The 'vote with your wallet' concept is flawed. People tend not to be able to correct the short term lower price for long term bad effects. Companies with an agenda to push and who can bear it a while financially can definitely buy your vote that way.
That's why a purely darwinistic capitalistic system, without a deeply entrenched system to protect the individual's rights against the wishes of the most powerful group, economically or otherwise, will eventually degrade into A Brave New World.
Just as the public protects its members, by law, from selling themselves as slaves, should it protect its members from selling their ability to communicate freely in a digital environment to the corporatii.
DRM turns your computer into a read-only device. It takes away your ability to share and communicate digital information freely. The Content Cartel wants to be able to tell you a secret without you being
It's a damn shame.
... that was up on slashdot a while ago. It allowed you to send messages that scrolled by on a 18x8 screen made of lamps in office rooms and play Pong on your GSM (see http://www.blinkenlights.de/).
It's not even that original, considering the fact that (at least here in NL) a lot of clip stations are continuously scrolling by SMS messages from random people. Everyone his 5 seconds of fame. Hmm.
The laser would be a fun way to ask a geeky other half to marry though.
Amen.
You'd record the part with the awful sounds on your cassette recorder, and then you could load it onto your Spectrum or C64 or MSX. Loads of fun!
The thing is, I think that software projects should be more viewed as the individual members of a population than the species as a whole. I.e. there's lots of parallel development, and relatively little change within each individual project.
A member can develop a feature (gene), but it does not get to other members (projects) until they are replaced by a new generation of offspring. Luckily a new version is sometimes enough, but often a new generation (rewrite or a completely new project) *is* what's needed to adopt revolutionary features developed elsewhere.
Of course you're completely right that this is nonsense when it comes to trivial things like resolution changers. But it's also natural that projects don't just copy *implementations* of trivial features if their maintainers think that those are badly done or don't fit their standards in other ways.
I think what you're seeing is very healthy behaviour. Everyone thinks that he can do slightly better than the other guy who has already done it. Of course, only 5 % will be right in that assessment, but who cares as long as in the end it does improve the state of the art.
People should be cautious not to suffer too much from a 'not invented here' syndrome, but reinventing the weel once in a while isn't bad at all if that makes a better mousetrap.
They are, but somehow I don't believe that anybody uses those for day to day work, or even play. I couldn't help thinking "what's the use, other than the visual experience that you'll be able to endure about 5 minutes". It's nice as an artwork example, but completely useless as an example of a well designed GUI.
Because I think that's what the cartels are eventually after: the people's very ability to communicate freely, privately, in a digital environment.
Why? Because what they effectively want is to be able to give someone a secret (i.e. a music track), while getting a guarantee that that person won't give the secret to anybody else.
In analogue space, it's obvious that getting such a guarantee is not possible without pulling the person's tongue out and/or cutting his hands, if you want to *guarantee*, beforehand, that he won't leak the information.
For some reason, in digital space people don't seem to object as much to converting their PCs to read-only devices, reducing the internet to clickable TV, and reducing freedom of digital expression to mere freedom of digital consumption.
The governments thinks it's fine too, because they think that they can provide more safety that way, because they are primarily appointed to take care of the economic status quo, and because creating a healthy environment for corporate power play is more important than to create a healthy environment for human creativity anyway.
It's a damn shame, but it seems this all happens because people are happy enough being mere consumers. This can go much further, see Huxley.
Society should fear when it encourages such behaviour though, instead of fighting it.
The problem is that some programmers tend to forget that to design is all about making choices. As that is a difficult activity, people tend to just 'make it a config option' and forget about the issue.
/Unix/ technology (that is pipes, sockets, processes, read, write, select, ioctl, mmap), and not with Corba, our COM-like thingy of the day or other funky fat binary interfaces, and not with multithreaded dlls that do not want to choose whether they are a process or a library. Let's not reinvent the OS in a very crappy and un-unixy way merely because we're building a GUI, for chrissakes. I really don't think the requirements of GUIs are so unique that that's needed. A module interface that allows each and every method in each and every every object to call each and every method in each and every other object in the system does not give any modularity, sorry. Think again. That's old-fashioned linking, worse, effectively going back to the days of single address space OSes by linking every application to every other, and that doesn't get you anywhere if you want to make standard, stable, secure component interfaces.
But people, configurability is good, but *putting the burden of 90% of UI design on the shoulders of the poor user* is not.
Indeed, because everybody effectively creates his own destkop environment because so little attention has been given to the *actual, practical, day-to-day, real-world* usability of the defaults, no effective feedback is provided to UI developers. The few advances in the field that are made are way too fragmented. This is a terrible waste.
We should strive to be able to build a *good, beautiful* UI. Not to demo the latest alpha blending feature, if it's ugly and confusing as hell. We should lean from Fitt's law, from people like Jeff Raskin, from Windows and MacOS 9, from OS X and X Windows and from people's gripes about all of those.
And, let's learn from Unix. We should build this UI using
You don't want to have 'more' to have a funky ad-hoc RPC interface so that it can be called by 'ls', or do you? We may need to extend the pipe concept if it's to limited for GUI app-to-app interfaces, but let's do that then, without resorting to plain, unrestricted RPC all the way. Please.
Let's keep it simple, and let's make it beautiful.
Aw, come on, moderators. Flamebait? Haven't you got *any* sense of humour?
This post was funny as hell.
The thing is, you can *request* anything, even for someone to keep a secret. But you're simply unable to *force* someone to keep a secret, with zero risk that it will leak, unless you exercise some drastic methods of aforementioned type (maim or isolate the person). But it's exactly that kind of methods that the content cartel want to impose on us, only in a digital sense. It demands from society that it applies that kind of methods to its citizens. And sadly, society thinks the short term economical benefits (money in campaign warchest! Cheap DVDs! Jobs provided by the RIAA members! Great!) are worth it.
It's a sad, sad, *sad* story.
The free-riding problem *cannot be solved* with digital information.
Companies only have their distribution mechanisms for digital information to compete with. If a CD distributor doesn't perform as well in the bandwith*convenience/price arena as your local ISP/telco, then it's a matter of *tough luck*, at least in a free market.
Oh, you want to publish something to some but keep it secret to others who haven't paid? You want to tell someone a secret but you want to guarantee, beforehand, that he cannot possibly tell another? *Tough luck*, unless you tell the secret and then rip out the other person's tongue and chop off his hands prevent him from further communicating with anybody else. The only way to make that happen digitally is to make every PC a read-only device. Oh, that's what you want then? But we already have that, you dumbf'ck, it's called TV. We don't want TV. We're sick of TV, and we won't allow our computers to be replaced by TVs just because some industry paid f'ck said so. Get over it.
RIAA, MPAA: the game is *over*. Cope. Please take your whining elsewhere, and please stop abusing society by buying f'cking laws.
When no good music gets recorded, no good books get written, no good movies get produced and no good paintings are being made anymore because the artists are starving, I'm sure society can come up with a *better* solution than simply handcuffing all its inhabitants, don't you think?
I'd say if you want to publish something digitally, you'll just have to live with the initial payment. If that's not enough, convince more people to pay before publishing it. If not enough people want to do so, then *tough luck*. If they do, all the better. It's still a free market after all, only one where the public is a *single* customer. If that customer wants to buy something valuable, he may have to make some savings up front. The concept is not even new, it already works fine for public highways. Society wants them, because society as a whole benefits from them, so society decides to pay for them as a whole. What's so f'cking hard about that?
Actually, x86's architecture for call gates and segment descriptors isn't that bad. To some extent, they are always needed; even the Linux kernel (which uses only paging, no segmentation) has to supply correct code, data and stack segment descriptors, and has provide interrupt gates (very similar to call gates) for the syscall and hardware interrupts.
The only drawbacks is that you have only four rings and that it's non-portable as hell. But it's very well documented, and works, too.
A setuid program is the exact software equivalent of a call gate, BTW. You need a certain privilege level to use the call gate, and after that, the routine uses the (possibly higher) privilege level set by the call gate. Exactly the same as having a setuid program that's executable only by a certain group. It's a very common (and useful) concept in both hard- and software.
There's nothing fundamentally wrong with the concept of setuid programs on Unix; you use them to check untrusted input before submitting it to higher privileged programs that need to trust it. The problem is that a lot of setuid programs don't do their job of checking input properly, or worse, don't treat environment variables as untrusted input as well.
(Aside: I've sometimes thought that Unix' way to connect applications to devices (read/write, seek, ioctl, that's it) is still so successful because it mimicks the way a CPU is connected to periferial devices in hardware: a data bus, an address bus and a few out-of-band control lines.)
From the introduction of the new paper: "However, the bottom line conclusion was that 'restructuring is essential' around a verifiable 'security kernel' before using Multics (or any other system) in an open environment (as in today's internet)".
Paragraph 3: "We hypothesised that professional penetrators would find that distribution of malicious software would prove to be the attack of choice."
Dropped in as a random sentence in paragraph 5, without much relation to the surrounding text: "Multics source code was readable by any user on the MIT site, much as source code for open source systems is generally available today."
From the conclusion of the new paper: "In nearly thirty years since the report, it has been demonstrated that the technology direction that was speculative at the time can actually be implemented and provides an effective solution to the problem of malicious software employed by well-motivated professionals. [...] And customers have said they have never been offered mainstream commercial products that give them such a choice, so they are left with several ineffective solutions [...]".
If you look at what is actually being demonstrated in the original paper, is that a monitor is needed that governs every memory access, without bypasses. The new paper admits that the VAX was the first to have this, and of course all modern MMUs do exactly that.
So what's the big deal? Why was this published at this time? If you read carefully, you can correctly conclude that we don't need no steenkin' Palladium to get secure systems today; we already have all the hardware features needed. However, if you skim the new paper, you could be led to believe that Palladium is absolutely essential...