Assuming the article contents are true, I think that the only thing by which this could be better than a Playstation 2 is the ability to play movies. There is no mention about graphic cards, and for a PC-like architecture they matter - a lot. The only processors Microsoft could work with are x86's and maybe StrongARMs, and I don't think they fare very well when compared to the PS2's. 64 megs of ram are a ridiculous amount, and the 4Gigs HDD is acceptable only for very specific purposes, like a "slow-ram"/swap area and high score tables.
I'll wait for more specs, but I'm absolutely unimpressed for now.
I'm talking about potentiality here. Anybody should be able to decide whether using it or not. Like it happens here (except that/. has a very basic concept of a killfile).
About killfiles: I use Gnus, which _also_ has a "decent" (sarcasm mode) scoring system. Damn, I spent god knows how many hours setting it up and fitting it to my necessities. Still, allowing the community to mark spam and flamebait as such would be an improvement, wouldn't it?
I am an avid Usenet reader, AND an avid/. reader. Some of the solutions the/. crew devised to try and keep the SNR (Signal to Noise Ratio) low are helpful IMO. My dream would be to see an Usenet-2 (or whatever you wish to call it) incorporating some of the ideas we see here. Of course, a distributed system would be a bitch to write and maintain (as opposed to the current/. centralized approach), but it would be an interesting challenge, wouldn't it?
(Verbally) fighting is right (as long as you don't insult). Flaming just means insulting, and losing whatever well-thought criticism there might be in a sea of harshness. It won't help you win a fight, just in expressing your frustrations.
Maybe, as someone posted, this is not "the" hole in the GPL. However, it's not a mistake to point out that problems with the GPL may exist (laws are not mathematically prove-able after all) and that discussing them is NEVER a mistake.
Whoever flamed Rob doesn't understand what a community is all about, and would deserve to be ignored.
So, welcome all and any discussion, here or wherever else.
Uhm... I am a native. "fonte" means more of a (smallish) fountain, but it's a somewhat archaic word (the commonly-used is "fontana"). "sorgenti" can be many things: it can be what you say, but it can also be a particular for of the "sorgere" verb, whose meaning would be "those which are rising". But it could also mean mean sources as in "programming code".
The word has many meanings, but (IMO) is not a very good marketing word: it has a bad "sound" to it, too many consonants, and is too ambiguous (the basic meaning is common, and implies something changing state or rising).
But in the end, it's just probably the last name of the company's founder:-)
profilo tecnico means "technical specifications" "sirio" is a very common telephone model here in Italy. Just your basic phone, nothing fancy. It's common because it's supplied by the (soon to be ex-) phone monopolist company.
Now about the press releases:
First one: SMAU '99 Communicate touch after touch TOUCHPHONE is the new easy-to-use telephone which makes using comunications systems easier: thanks to a big touchscreen, all functions can be activated by simply touching a display. (skip, they talk about where it will be introduced to the public). The TOUCHPHONE is an intelligent telephone, an instantaneous Internet access, a PDA, an answer machine, an e-mail manager; a synthesis of the higher electronic technology, expressed as an intelligent product allowing simple and fast communications. Thanks to its versatile technology, and to the OS WindowsCE, the Touchphone allows new functions and services for its users. (skip, it talks of dedicated services from some commercial partners, including banks and phone companies). With a modern and elegnant design, TOUCHPHONE adapts to different settings in an essential and beautiful manner. produced by: Sorgenti s.r.l. Via Borgomanero 13 28040 Paruzzaro (NO) Tel. +39-0322-230071 Fax. +39-0322-538400
Notice: SMAU is Italy's biggest IT showcase (If I remember correctly, we're talking about 1 million visitors in 5 days). It's held at the beginning of November.
The second press review is very short, and only deals with the thing's price: Lit. 1.400.000, or 723 Euros (or USD).
The word "Sorgenti" that's all over the place is the producer's name: it translates to "Sources".
AFAIK the distinctive point about Microkernels is that cricical subsystems (filesystems, memory management policies, process scheduling policies etc.) are handled by user-level processes.
NT has a lot many services, its IPC setup is most impressive (I think it's because Microsoft tries to offer (N+1)-thousand way of doing things because they can't get the first N-thoudsnd right but need to support them anyways), but I haven't seen anything like "filesystem-as-a-process". From this point of view, Linux (with its nfsiod "processes") is more akin to a microkernel than NT is.
About whether a microkernel is better than a monolithic one. Some time around 1994 there was a very famous flamewar between a certain... what's his name... oh yes. Torvalds. Linus Torvalds, and a professor Andrew Tannenbaum (or was it Tannembaum? not sure), author of the Minix OS (and of the Amoeba distributed OS, but I've never seen any reference to it but in a Tannenbaum book). The Torvalds guy argued that Microkernels are but an academics' toys, because the advantages they offer don't hold in real life(TM), or at least aren't worth the effort. Tannenbaum of course defended microkernels (he is an academic after all), in fact both Minix and Amoeba are designed as microkernels.
Linux _IS_ a monolithic kernel. It is also a modular kernel. But so is Win95 (don't know about WinCE).
The distinction is between Monolithic Kernels and MicroKernels. The difference is that Monolithic kernels handle everyhing needed _inside_ the kernel, while MicroKernels delegate certain parts of the OS (i.e. filesystems, Process Management and advanced scheduling) to some "special" processes. See Minix (I've seen it) or Mach.
Actually some aspects of Linux are more alike to microkernels (flush daemon, update daemon, NFS client...), so I'd put the Linux design somewhere inbetween monolithic and microkernel, closer to the former.
All this just to tell you that you used the wrong word:-)
Sure, it was not my intention to make wrong assumptions.
(notice, I'm entering dangerous waters here, it's not my intention to start a flamewar). The point is not the "Christian" part, but the message we get from there. If you think about it, the basic Christian precept ("Do not do unto others what you wish not be done to you" - I might have got the words wrong) is, stripped from its religious concepts, one of the very few (moral, ethic, choose your word) principles that can keep a society as a whole cohesive, expressed in amazing clarity and brevity. And the same applies to many other "precepts", INCLUDING charity. I chose to use the name "Christian Charity" because it's something that's generally well-known, but there should be similar concepts in Islam, Induism, Buddhism and just every major religion in the world.
My point was: "The assumption everybody who freely shares what he has is a communist is broken at the root, let's not fall into that trap." The idea of freely sharing has probably been around since mankind exists, and has been formalized as religious concepts at least two millenia ago.
So ok, maybe "Christian Charity" is not a fully representative expression, and "Charity" by itself has too much of "pity" sound to it. But then, it is just as wrong as "Communist". Let's just call it "Free Sharing" and leave the politics out of this...
These, of course, are just my opinions. Feel free to disagree:-)
The issue you talk about then is not as much a technical one as an organizational one. The point in your example would be for the packagers to agree on an appropriate set of capabilies to specify. In your example, one possible solution could lie in specifying virtual capabilities ("provides") akin to these:
package sendmail: provides: MTA MTA-name
package qmail: provides: MTA
package debbugs: requires: MTA MTA-name
and the icompatibility would be correctly handled when installing (provided that such incompatibilities be known: it could very well be that you discovered this one while trying to install debbugs).
Such an package dependencies tracking mechanism wouldn't be exceptionally easy to maintain, especially with the kind of organization model debian uses, because it requires a lot of timely inter-packager communication, and a very flexible work model (notice: I am NOT a debian package maintainer, so I have no clue about how tightly knit is the packagers' network: I am assuming that it must be a tad looser than a company's communications network, for no other reason that a company's employees usually work full-time on that company's projects, thus drastically cutting answer times). BUT it would handle the problem elegantly.
Also notice: I have NOT mentioned any package-manager here. This solution works equally well with any package manager that supports virtual capabilities and dependencies tracking.
The point about the install-script has already been made in another post.
I'll object to the others: "For example, rpm allows you to have multiple versions of a single package installed." That's not entirely true: RPM will allow that by default (provided that there's no file conflict), and this can sometimes be useful if you wish to have multiple versions of a library on your system for backwards compatibility purposes.
However, the packager is given the choice to state a "conflicts" clause, which supports version information. So to emulate dpkg, packagers should simply assert that some version conflicts with all earlier versions, and the trick is done.
Now about the other one: "One problem with rpm-packages is that it is harder to satisfy dependency due to the concept of file-dependencies. Instead of being able to say `I need package b to be able to use package a' it can become `I need file/usr/lib/libfoo.so.3.14 to be able to use package a' and then you'll have to find some way to scan all packages to see which ones include that file, and then you're not even sure if they have the right version of that file.. "
Again, this is not entirely accurate: RPM allows a packager to specify a "Virtual capability": Simply put, a package foo can assert to provide a capability bar, and other packagers can express dependencies to the bar capability, rather than the libfoo file.
I'm not saying this to bash dpkg in favor of RPM, but just to set some facts straight. For instance, I like dpkg's "recommended" dependencies (as opposed to RPM's only "hard" dependencies). I think the two technologies are roughly equivalent, and that Wichert is oh-so-right in saying that in the end the choice boils down to personal tastes, familiarity and stability.
Cringley's remedy is flawed at the root: his points do make sense where he talks about economical aspects, less when he deals with the technical stuff.
The pivotal point of his idea is for Microsoft to spin off its Development Tools division, so that when they want to add a feature to the OS, they need to inform that division in order to build programs supporting that new feature.
And here is the flaw: it's _NOT_ the compiler interfacing with the OS: it's a library, one that is not necessarily (in fact, I think it seldom is) provided by the same packager as the development tools (see the GNU field: glibc is not distributed with gcc).
So spinning off the DevTools division would pose n limitation whatsoever on the way Microsoft develops its applications, and their undocumented (and privileged) ties to the OS.
Forcing Microsoft to release its source code would have many pros and cons, which have nothing to do with Free Software.
Free Software (as in speech) is all about allowing people to improve on a piece of software, and make derivative works off it. Forcing Microsoft to release the source code for its products has the purpose to make harmless the biggest weapon Microsoft has against its competitors: the intimate knowledge of the applications' (and OS') internals.
In fact I believe that, if such a road be taken, only the OS should be "uncovered" (I wouldn't call this "opened"), as THAT is the main leverage Microsoft has to create "superior" products on the applicative area. Also, I wouldn't advise for the OS to be released in Open Source-ish terms: it would be perfectly fine for the OS to be released only under NDA, and without the right to create any derivative work, but access to it should be granted to anyone requesting it. This because the OS internals are (legitimately) an intellectual property of the writer, and that should be respected as long as this right is not misused (as Microsoft has done in the past).
This said, Microsoft already "failed" (in the Caldera vs. Microsoft lawsuit) to provide the source code to Windows 95....
All the various distributed computing efforts have something in common: while they all require extensive processing resources, they all need very little data to work on. Basically they just need to synchronize: in the case of the famous distributed.net RC5-64 contest, they just need to decide who will try a given set of blocks.
Sequencing the DNA seems (I don't have the title to claim otherwise) to be not that much a matter of computing power, but of an immense dataset to work on.
It wouldn't be possible to distribute that much information in terms reasonable enough to make the effort worthwile.
ST (was SGS-Thompson) used to do 486 clones (Maybe under license from Cyrix or something like that).
That isn't to say there aren't chip manifacturers in Europe (in fact, there should be a few of them). Just that they haven't gone for the high-end x86 market, nor probably will because playing catch-up with Intel (and AMD) would be pretty unworkable.
Actually, you should just not do or say anything at all. Not even buying a computer in the first place, because that would make you a "hacker" (you know, those dangerous, psychotic individuals who use computers and the Internet...).
Slashdot Mirror
Assuming the article contents are true, I think that the only thing by which this could be better than a Playstation 2 is the ability to play movies.
There is no mention about graphic cards, and for a PC-like architecture they matter - a lot.
The only processors Microsoft could work with are x86's and maybe StrongARMs, and I don't think they fare very well when compared to the PS2's.
64 megs of ram are a ridiculous amount, and the 4Gigs HDD is acceptable only for very specific purposes, like a "slow-ram"/swap area and high score tables.
I'll wait for more specs, but I'm absolutely unimpressed for now.
is blaming this community of attempting DOS attacks for being slashdotted...
Windows is not vulnerable to these attacks, like
Melissa showed us so wonderfully no more than
6 months ago
(sarcasm off)
Really guys, I'm surprised our historic memory is
so short. We should shove FACTS in these people's faces.
I think not more than the analog nature of electric, electromagnetic and light signal is, the basic approach could be the same.
I'm talking about potentiality here. Anybody should be able to decide whether using it or not. Like it happens here (except that /. has a very basic concept of a killfile).
About killfiles: I use Gnus, which _also_ has a "decent" (sarcasm mode) scoring system. Damn, I spent god knows how many hours setting it up and fitting it to my necessities.
Still, allowing the community to mark spam and flamebait as such would be an improvement, wouldn't it?
I am an avid Usenet reader, AND an avid /. reader. /. crew devised to try and keep the SNR (Signal to Noise Ratio) low are helpful IMO. /. centralized approach), but it would be an interesting challenge, wouldn't it?
Some of the solutions the
My dream would be to see an Usenet-2 (or whatever you wish to call it) incorporating some of the ideas we see here. Of course, a distributed system would be a bitch to write and maintain (as opposed to the current
fight != flame
(Verbally) fighting is right (as long as you don't insult). Flaming just means insulting, and losing whatever well-thought criticism there might be in a sea of harshness. It won't help you win a fight, just in expressing your frustrations.
Maybe, as someone posted, this is not "the" hole in the GPL. However, it's not a mistake to point out that problems with the GPL may exist (laws are not mathematically prove-able after all) and that discussing them is NEVER a mistake.
Whoever flamed Rob doesn't understand what a community is all about, and would deserve to be ignored.
So, welcome all and any discussion, here or wherever else.
Uhm... I am a native.
:-)
"fonte" means more of a (smallish) fountain, but it's a somewhat archaic word (the commonly-used is "fontana").
"sorgenti" can be many things: it can be what you say, but it can also be a particular for of the "sorgere" verb, whose meaning would be "those which are rising".
But it could also mean mean sources as in "programming code".
The word has many meanings, but (IMO) is not a very good marketing word: it has a bad "sound" to it, too many consonants, and is too ambiguous (the basic meaning is common, and implies something changing state or rising).
But in the end, it's just probably the last name of the company's founder
"sirio" is a very common telephone model here in Italy. Just your basic phone, nothing fancy. It's common because it's supplied by the (soon to be ex-) phone monopolist company.
Now about the press releases:
First one:
SMAU '99
Communicate touch after touch
TOUCHPHONE is the new easy-to-use telephone which makes using comunications systems easier: thanks to a big touchscreen, all functions can be activated by simply touching a display.
(skip, they talk about where it will be introduced to the public).
The TOUCHPHONE is an intelligent telephone, an instantaneous Internet access, a PDA, an answer machine, an e-mail manager; a synthesis of the higher electronic technology, expressed as an intelligent product allowing simple and fast communications. Thanks to its versatile technology, and to the OS WindowsCE, the Touchphone allows new functions and services for its users. (skip, it talks of dedicated services from some commercial partners, including banks and phone companies).
With a modern and elegnant design, TOUCHPHONE adapts to different settings in an essential and beautiful manner.
produced by:
Sorgenti s.r.l.
Via Borgomanero 13
28040 Paruzzaro (NO)
Tel. +39-0322-230071
Fax. +39-0322-538400
Notice: SMAU is Italy's biggest IT showcase (If I remember correctly, we're talking about 1 million visitors in 5 days). It's held at the beginning of November.
The second press review is very short, and only deals with the thing's price: Lit. 1.400.000, or 723 Euros (or USD).
The word "Sorgenti" that's all over the place is the producer's name: it translates to "Sources".
"Intel Processor 2000"
(sorry, couldn't resist...)
Are sun's compilers that bad?
AFAIK the distinctive point about Microkernels is that cricical subsystems (filesystems, memory management policies, process scheduling policies etc.) are handled by user-level processes.
NT has a lot many services, its IPC setup is most impressive (I think it's because Microsoft tries to offer (N+1)-thousand way of doing things because they can't get the first N-thoudsnd right but need to support them anyways), but I haven't seen anything like "filesystem-as-a-process". From this point of view, Linux (with its nfsiod "processes") is more akin to a microkernel than NT is.
About whether a microkernel is better than a monolithic one. Some time around 1994 there was a very famous flamewar between a certain... what's his name... oh yes. Torvalds. Linus Torvalds, and a professor Andrew Tannenbaum (or was it Tannembaum? not sure), author of the Minix OS (and of the Amoeba distributed OS, but I've never seen any reference to it but in a Tannenbaum book). The Torvalds guy argued that Microkernels are but an academics' toys, because the advantages they offer don't hold in real life(TM), or at least aren't worth the effort. Tannenbaum of course defended microkernels (he is an academic after all), in fact both Minix and Amoeba are designed as microkernels.
Linux _IS_ a monolithic kernel. It is also a modular kernel. But so is Win95 (don't know about WinCE).
:-)
The distinction is between Monolithic Kernels and MicroKernels. The difference is that Monolithic kernels handle everyhing needed _inside_ the kernel, while MicroKernels delegate certain parts of the OS (i.e. filesystems, Process Management and advanced scheduling) to some "special" processes.
See Minix (I've seen it) or Mach.
Actually some aspects of Linux are more alike to microkernels (flush daemon, update daemon, NFS client...), so I'd put the Linux design somewhere inbetween monolithic and microkernel, closer to the former.
All this just to tell you that you used the wrong word
Did you know that when you lend a friend one of your (rightfully bought) CDs, you're infringing copyright?
Sure, it was not my intention to make wrong assumptions.
:-)
(notice, I'm entering dangerous waters here, it's not my intention to start a flamewar).
The point is not the "Christian" part, but the message we get from there. If you think about it, the basic Christian precept ("Do not do unto others what you wish not be done to you" - I might have got the words wrong) is, stripped from its religious concepts, one of the very few (moral, ethic, choose your word) principles that can keep a society as a whole cohesive, expressed in amazing clarity and brevity. And the same applies to many other "precepts", INCLUDING charity.
I chose to use the name "Christian Charity" because it's something that's generally well-known, but there should be similar concepts in Islam, Induism, Buddhism and just every major religion in the world.
My point was: "The assumption everybody who freely shares what he has is a communist is broken at the root, let's not fall into that trap." The idea of freely sharing has probably been around since mankind exists, and has been formalized as religious concepts at least two millenia ago.
So ok, maybe "Christian Charity" is not a fully representative expression, and "Charity" by itself has too much of "pity" sound to it. But then, it is just as wrong as "Communist". Let's just call it "Free Sharing" and leave the politics out of this...
These, of course, are just my opinions. Feel free to disagree
Cheers
I think it's called Christian Charity.
And it is just a couple of years older than Communism.
The issue you talk about then is not as much a technical one as an organizational one.
The point in your example would be for the packagers to agree on an appropriate set of capabilies to specify.
In your example, one possible solution could lie in specifying virtual capabilities ("provides") akin to these:
package sendmail:
provides: MTA MTA-name
package qmail:
provides: MTA
package debbugs:
requires: MTA MTA-name
and the icompatibility would be correctly handled when installing (provided that such incompatibilities be known: it could very well be that you discovered this one while trying to install debbugs).
Such an package dependencies tracking mechanism wouldn't be exceptionally easy to maintain, especially with the kind of organization model debian uses, because it requires a lot of timely inter-packager communication, and a very flexible work model (notice: I am NOT a debian package maintainer, so I have no clue about how tightly knit is the packagers' network: I am assuming that it must be a tad looser than a company's communications network, for no other reason that a company's employees usually work full-time on that company's projects, thus drastically cutting answer times). BUT it would handle the problem elegantly.
Also notice: I have NOT mentioned any package-manager here. This solution works equally well with any package manager that supports virtual capabilities and dependencies tracking.
The point about the install-script has already been made in another post.
/usr/lib/libfoo.so.3.14 to be able to use package a' and then you'll have to find some way to scan all packages to see which ones include that file, and then you're not even sure if they have the right version of that file.. "
I'll object to the others:
"For example, rpm allows you to have multiple versions of a single package installed."
That's not entirely true: RPM will allow that by default (provided that there's no file conflict), and this can sometimes be useful if you wish to have multiple versions of a library on your system for backwards compatibility purposes.
However, the packager is given the choice to state a "conflicts" clause, which supports version information. So to emulate dpkg, packagers should simply assert that some version conflicts with all earlier versions, and the trick is done.
Now about the other one:
"One problem with rpm-packages is that it is harder to satisfy dependency due to the concept of file-dependencies. Instead of being able to say `I need package b to be able to use package a' it can become `I need file
Again, this is not entirely accurate: RPM allows a packager to specify a "Virtual capability": Simply put, a package foo can assert to provide a capability bar, and other packagers can express dependencies to the bar capability, rather than the libfoo file.
I'm not saying this to bash dpkg in favor of RPM, but just to set some facts straight.
For instance, I like dpkg's "recommended" dependencies (as opposed to RPM's only "hard" dependencies).
I think the two technologies are roughly equivalent, and that Wichert is oh-so-right in saying that in the end the choice boils down to personal tastes, familiarity and stability.
Cringley's remedy is flawed at the root:
his points do make sense where he talks about economical aspects, less when he deals with the technical stuff.
The pivotal point of his idea is for Microsoft to spin off its Development Tools division, so that when they want to add a feature to the OS, they need to inform that division in order to build programs supporting that new feature.
And here is the flaw: it's _NOT_ the compiler interfacing with the OS: it's a library, one that is not necessarily (in fact, I think it seldom is) provided by the same packager as the development tools (see the GNU field: glibc is not distributed with gcc).
So spinning off the DevTools division would pose n limitation whatsoever on the way Microsoft develops its applications, and their undocumented (and privileged) ties to the OS.
Forcing Microsoft to release its source code would have many pros and cons, which have nothing to do with Free Software.
Free Software (as in speech) is all about allowing people to improve on a piece of software, and make derivative works off it.
Forcing Microsoft to release the source code for its products has the purpose to make harmless the biggest weapon Microsoft has against its competitors: the intimate knowledge of the applications' (and OS') internals.
In fact I believe that, if such a road be taken, only the OS should be "uncovered" (I wouldn't call this "opened"), as THAT is the main leverage Microsoft has to create "superior" products on the applicative area. Also, I wouldn't advise for the OS to be released in Open Source-ish terms: it would be perfectly fine for the OS to be released only under NDA, and without the right to create any derivative work, but access to it should be granted to anyone requesting it.
This because the OS internals are (legitimately) an intellectual property of the writer, and that should be respected as long as this right is not misused (as Microsoft has done in the past).
This said, Microsoft already "failed" (in the Caldera vs. Microsoft lawsuit) to provide the source code to Windows 95....
All the various distributed computing efforts have something in common: while they all require extensive processing resources, they all need very little data to work on.
Basically they just need to synchronize: in the case of the famous distributed.net RC5-64 contest, they just need to decide who will try a given set of blocks.
Sequencing the DNA seems (I don't have the title to claim otherwise) to be not that much a matter of computing power, but of an immense dataset to work on.
It wouldn't be possible to distribute that much information in terms reasonable enough to make the effort worthwile.
ST (was SGS-Thompson) used to do 486 clones (Maybe under license from Cyrix or something like that).
That isn't to say there aren't chip manifacturers in Europe (in fact, there should be a few of them). Just that they haven't gone for the high-end x86 market, nor probably will because playing catch-up with Intel (and AMD) would be pretty unworkable.
Actually, you should just not do or say anything at all. Not even buying a computer in the first place, because that would make you a "hacker" (you know, those dangerous, psychotic individuals who use computers and the Internet...).
We're about to have a big-time DSL rollout here - at fairly cheap prices, I think.
The cost of an ADSL dubscription will be
Lit 400.000 (US$ 205) for installation
and then
Lit. 660.000 (US$ 350) per year, for 640 kbit
then there's the Internet connectivity cost, which is rumored to be about Lit. 2.000.000 (US$ 1100) per year, depending of course on the provider.
We're currently in the process of dismantling our former phone carrier monopoly, those prices might drop in a couple of years.