Unfortunately, a lot of the alternatives are like, "let's make something new, that's going to suck for the near future until we get the kinks worked out." Sure, they'll eventually become something great but for the present they're not really appropriate for a major project like KDE.
Well, I can't speak to the maturity of the others, but Vesta is the result of over a decade of R&D and has been in production use for microprocessor design projects at Compaq and Intel for over 6 years. Vesta's period of "trying something new" happened a long time ago, and the kinks have been worked out for years.
That's not to suggest that it's static (Intel employs two full-time software engineers to work on it), but it's been stable for a long time.
Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.
...Linus didn't discover
Vesta
before he started implementing git. The core of the two are very
similar.
Linus said "git is not an SCM. it's a filesystem designed to host an SCM". The Vesta repository is a filesystem. It has a versioning system (and a builder) built on top of it.
git's backing store is indexed by a hash of the file contents, just like Vesta's.
git stores complete copies of files, but only one copy of each file, just like Vesta.
Of course there are some important differences. Like the fact that Vesta's been around for over a decade, and has been in
production use for microprocessor design at Compaq and Intel for over
6 years.
Just to be absolutely clear: I've only ever communicated with this person on-line, and I can't verify who they are in real life or that they actually work for Comair. It seemed credible though, and it seemed worth posting to de-bunk the slashdot knee-jerk reaction of blaming Microsoft. To me, an application using a 16-bit integer for something seems like a very likely explanation.
Someone from Comair (who shall remain anonymous) provided me with
some details whch people here would be interested in:
The computer system in question runs AIX. The box itself is still up
and running just fine; this is purely an application error. This
application was not written in-house at Comair, but by another large
aerospace company -- SBS
(http://www.sbsint.com/, owned by
Boeing.) This bit of software does not use an external database, it
tracks everything itself. It is a dedicated system responsible only
for flight crew assignments. (The blather in the original submission
about passenger reservations is way off-base. Those functions are
handled by a completely different system.)
The great majority of Comair's traffic flows through the midwest, and
the central base of operations is in Cincinnati. The midwest was hit
by a major snowstorm this week, causing many, many crew reassignments.
It appears right now that the application in question has a hard limit
of 32,000 changes per month (ouch). Consider that Comair runs 1,100
flights a day and there are usually 3 crew members on each aircraft.
A big storm like this can cause problems for days after the snow stops
falling. That's a whole lot of crew changes.
In Comair's defense, this has never happened before and is unlikely to
happen again. The crew system was already on the chopping block long
before this incident, with its replacement scheduled to go live in
January. If this freak storm had happened a month later, this likely
never would have occurred.
Maintainer, yes. Person who ported it to Linux and got it released as free software, yes. Author, no. (I am Ken Schalk, so I should know.:-)
Vesta was written by researchers at the Digital/Compaq Systems Research Center in Aplo Alto, CA. I've certainly tried to make a useful contribution, but I did not create it.
It runs just fine on Linux (x86 and Alpha, PowerPC in the works).
I have no idea what STARLA is (and since I'm Vesta's primary maintainer/build master I think I'd know).
AFAIK, Vesta (at least Vesta-2, which is the free software version) never ran on VMS. (It uses NFS and chroot, so I'd be really surprised to see a VMS port.)
A couple other posts have mentioned Vesta, which goes a long way
towards meeting the requirements you lay out. (For the sake of
disclosure, it's only fair to mention that I am currently the primary
maintainer of Vesta, and am somewhat responsible for getting it
released as free software.)
1. atomic commits - your change happens only if all the
files can be processed. This prevents a corrupted workspace
when CVS processes half your files in a commit and then exits
on an error throwing the other half of your files on the floor.
Vesta absolutely does this.
2. change list management - all commits have a unique
reference number. CVS process files by directory instead of
by workspace, so it is impossible to tell which files are
associated with a commit.
Vesta does not explicitly provide this, however it's very easy to get
with a simple diff command. The Vesta repository has a
filesystem interface which makes it possible to directly access all
versions past and present. A simple diff -r will show
exactly what changed between any two versions. The also has other fun
uses (e.g. greping across versions).
3. access control by workspace or workspace directory - the
ability to give certain users or groups access to certain
workspaces or directories. Ideally, access control can be by
done by bug id.
Vesta's access controls are essentially UNIX file permissions.
Through the repository's filesystem interface, you can control who can
read and write (commit new versions) at a variety of granularities
with chown, chgrp, and chmod.
4. graphical resolve of conflicts - a graphical three-way
diff is the only way to resolve complex conflicts
Vesta provides no direct help here, but again, because of the
filesystem interface to the repository, it's easy to apply standalone
diff/merge/conflict resolution tools.
5. The ability to move files and directories and maintain
file history and label integrity from the client. CVS
requires the whole workspace to be locked so that moves can
be performed on the server side and does not maintain label
integrity.
Vesta's unit of version control is a directory. Between versions,
files and subdirectories can be added, removed, renamed, etc.
6. web viewer and graphical difference viewer - the ability
to browse via the web change set lists to see what files
changed and what the actual differences were.
7. the ability to integrate workspaces across projects - the
ability to arbitrarily merge/integrate any source code from
any project to any other project.
Vesta includes sophisticated cross-site features, including
replication and remote checkout/checkin. It's been successfully
applied before by a team spread across the US east and west coasts
with hundreds of megabytes of sources.
8. powerful labeling features (parallel development and
prior version support).
9. rollback or undo multiple changes - this is great way to
recover from a developer commit disaster.
Vesta really shines in these areas. Vesta is also a build tool, and
every build neccessarily includes a complete specification of the set
of immutable versions it uses. Builds are also themselves immutably
versioned. This makes it easy to determine which source componenets
have changed between two versions of a build. Also, since it's as
easy to select any historical version as it is the latest one, rolling
back changes is trivial.
10. multi platform support - must run on all platforms.
We're still working on it (at the moment just Linux and Tru64 work),
but hey, it's free software, and we'd love to have more
developers/porters.
11. command line and graphical interface. Command line for
scripts and graphical interface for those who can't work
without it.
At this point there's a command-line interface and some rudimentary
support for repository operations in the web interface. Again,
it's free software, and we'd love to have somebody contribute more
layered tools.
12. push and pull notifications - built in support for e-mail
and news group notification of changes in the workspace.
Nothing built-in yet, but we've been talking about doing it, and it
may happen soon.
As noted in the
Inquirer's article on Vesta, it was used by the Alpha
microprocessor group on the EV8 (aka Araña) project.
Most of the people who used Vesta on that project are now a
part of Intel, working on a future IA-64 processor. They
are continuing to use Vesta under Intel.
(For the sake of disclosure, I'm one of the people who
worked on that project and now work for Intel.)
I kinda figured it wouldn't take long for someone to bring
up the spectre of Vesta as a Trojan and reference that
classic Thompson piece.
You could certainly do what you describe. Feel free.
Extract the sources from the Vesta repository, re-write the
entire build description in make, and re-build. (We
actually have a web interface to the repository that we're
hoping to put up soon so that people can examine and even
download the source without having to install Vesta.)
In fact, I challenge anyone so inclined to try and uncover
any malicious code in the binaries we've released. It would
be nice if someone who was not only paranoid enough but also
motivated enough to follow through with that came out of the
woodwork. Then perhaps we could have a better response for
the next person to cast such aspersions.
We're not distributing tarballs of source for exactly the
reason stated in the FAQ: you wouldn't be able to build it
without writing new build instructions for make or
some other builder. I don't have the time or inclination to
write Makefiles to build Vesta. If somebody else
wants to, that's fine, that's why its free software.
That's not the way you would use it for collaboration.
The NFS interface is not intended for wide-area access, only
for clients within an installation (which can be as small as
one system).
The right way to use it is for each contributor to run
their own Vesta repository and use Vesta's
replicator to keep up to date with other repositories
(such as a central master). Vesta's
checkout tool automatically contacts the master
repository, even if it's remote, and its
checkin tool replicates the checked-in version back to
the master repository.
We already have several users who work this way, one even
running their Vesta repository at the other end of a 56k
dialup line.
(BTW, I'm the current maintainer, the one who did much
of the work of getting it ported to Linux and released.)
...I'm going to Burning Man, and have been considering a project with a bunch of embedded Linux-based devices. I was trying to think of a way to power them that would neither involve a noisy gas-powered generator nor a huge quantity of batteries. (Solar cells would work during they day, but night-time operation would be essential.) This may not be the right solution considering other design constraints, but I'm going to keep it in mind.
Now, if that was patented technology, then why were he specs on the web for all to see???
I think a better question would be "Did they apply for their patents before the spec was published?" I honestly didn't pay enough attention in the early days of CDDB, but I'd guess that the publication of the spec pre-dates their patents. IANAL, but as patent law has been explained to me, you shouldn't be able to patent something that's been previously published. In fact, I know my company sometimes will publish papers to prevent our competitors from getting a patent on a piece of technology.
It pains me to admit it, but the market for Linux on non-x86 platforms just isn't as big. (I run Linux on Alpha, PPC, ARM, and x86 at home, Alpha nd x86 at work. Oh, and I work in the Alpha microprocessor group.)
One of the classic strengths of open source and free software is code quality improvement through peer review. The trouble is, most of the people testing and debugging are on x86. So you get better coverage, more bugs found, and more bugs fixed on x86 than on any other platform. Second tier platforms don't do as well because they have a smaller user base, and thus a smaller developer base.
In other words, support for x86 is less suceptible to bit rot, because the features get exercised more often.
Just one example is the kernel source. Virgin 2.4.3 fails to build on Alpha. (How exactly did Linus et. al. miss that?) While it built and ran on my PPC machine, it ignored keyboard and mouse input. (Aparently nobody noticed the ADB support for older machines was broken.)
Compaq literally shovels money, hardware, and other resources at RedHat to keep Alpha in its line of supported platforms. It's worth more to us to have it than it is to them.
IMHO, open source project leaders shoulds actively try to get their code tested on as many different platforms as possible. It shakes out additional bugs and improves the code. (And I don't just mean CPU architectures. If it works on x86/Linux, check it on ARM/NetBSD, Sparc/Solaris, PPC/MacOSX, and every other paltform you can get your hands on.) Unfortunately, that takes time, effort, hardware, and other resources that are usually in short supply.
You don't get front-page articles on slashdot about people putting locks in shops to stop people to stealing the merchandise, so why should it be any different when try and stop other kinds of crime that costs money?
But it doesn't cost money. Copying information is not the same thing as stealing a physical object, because copying takes nothing from the creator of the information. It just doesn't give them anything.
Intellectual property protection is the creation of artificial scarcity. If you don't speak Econ 101, that means it's like charging people money for breathing air. There's plenty of air, it's not a scarce resource. Information is the same, because you can make as many copies as you want without diminishing the original.
It's never the big boss that gets hurt. [...] It's the man who's packing the videos for $8/hour. It's the guy making them. He's the one losing the money.
I suppose we should also cry for those poor guys at Netpliance too, huh? Or how about all the people who build their houses on a flood plain?
As bandwidth and storage become cheaper (and thanks to good old Gordy Moore, they will continue to), unauthorized copying of information will become more and more common. There's just no stopping it. Eventually, most, and maybe even all business models based on charging money for copies of strings of 0s and 1s will collapse. This is just a fact of the nature of our reality. Personally I think it makes morse sense to figure out how to live in the world we're heading for, rather than jumping up and down screaming about how wrong it is.
Re:Time for some education on computer architectur
on
Emergence of SMT
·
· Score: 1
It might interest you that Digital was very enthusiastic about
it, and intended the Alpha 21464 to be built around this notion. Who knows if we'll ever see a 21464 now, though...
I do. I've been working on it for several years now. The project is alive and well, and we fully intend to deliver an SMT processor. Of course delivery is still a couple years off (designing processors takes a really long time), but we'll get there eventually.
BTW, for those of you interested in SMT, we are hiring.
P.S. Great response to the nay-sayer. Wish I had written it.:-)
To me this sounds like a fabulous idea, though it's obviously not yet developed to the point of being practical for day-to-day use. And I don't think the benefits are limited to having multiple represntations of the language.
Large software systems get very hard to manipulate and understand. It becomes particularly hard to answer questions about the code. For example, given 10,000 lines of C++, do the following:
Find every function with an incorrect exception specification (i.e. a function could throw X, but it's not in the functions declared list of exceptions, and thus could halt the program as an unexpected exception). Be sure to find the site from which the exception can be thrown as well (which could be buried several calls deep from the function with the bad exception spec).
Find every place where virtual method X on derived class Y can be called (which means you have to find every place that method could be called on the superclass(es)). (And no, "X" is not a unique bit of text.) For extra fun, make the method an overloaded operator.
Statically check for any cases where the expression in an assert may not be true. (OK, so there's thorny logic manipulation problems in this one, but you could find many of the simple mistakes, which one often runs into.)
To do any of the above, you would first need to parse the code to discover its semantics and represent them in a way that you could examine in detail with a program. Writing even a simple parser is a little difficult. Parsing C++ correctly is very difficult.
Being able to directly access the true semantics of a program would make solving these kinds of problems feasible. I'm sure we can all imagine other fun things it would enable as well.
How much does it cost to recompile a piece of code after modifying the source? Basically nothing. How much does it cost to fab a new chip after modifying the design? Millions of dollars.
I'm not saying that there aren't advantages to open source hardware (and there are precedents). But the advantages aren't as big as for software because not as many people can realistically participate. Let's look at some of the classic stated advantages of open source software:
Anybody can fix it when it breaks. Not so with hardware. Even if you could identify the problem in the hardware description (which is often very difficult, even for people with an intimate knowledge of the design and more debugging resources than the Joe Average Hacker), writing a patch gets you nothing. You're not going to pay to fab a new run of wafers, so you still have to wait for the vendor. Plus, they will still have to verify that your patch works in all cases and doesn't cause new problems, and design verification takes more time than design itself.
You can tweak it for your needs. Again, are you going to pay to fab custom chips with that hardware gnutella client? I don't think so. There's also the problem of verification, which is really difficult and time consuming.
"Given enough eyeballs, all bugs are shallow" (Linus' law). Given that you don't have either the above two advantages, how many of you are going to take the time to a) learn Verilog/VHDL and b) get to know the code well enough to debug hardware failures? Also, how many of you have a logic analyzer, oscilloscope, etc.? I'm thinking the number of eyeballs involved from the general hacker community will be within epsilon of zero.
No, it was a bogus test. The author did "make bzImage" for the uniprocessor test and "make -j3 bzImage" on the multiprocessor test.
Read the article again. They did both of these tests on exactly the same machine. Single-threaded make on a dual-processor machine is not equivalent to single-threaded make on a uni-processor. Just because make is only forking one compiler run at a time doesn't mean that there's only one task ready to execute on the machine. You can expect to get at least some improvement from parallelism between the kernel and the userspace code that's executed, and from other little things like the fact that you don't have to context switch from the compiler to the xterm process to the X server just to update the screen with the latest output.
It was a bogus test, for this and many other reasons which I won't bother repeating.
[Not that its flaws make me want one any less. This makes my Abit BP6 seem pathetic by comparison.]
Anybody running a pre-open-source Interbase seems to have only really unpleasant choices:
Use a binary-only patch (if it's even available for the version they're running) which fixes the problem and trust that they really did remove the backdoor and didn't just replace it with a different one (which I know I wouldn't be willing to do given the fact that they put it in there in the first place)
Spend an unknown amount of time and effort (and as we all know, time = $) to update to a new version which they know can be trusted (because they can compile it themselves)
The overhead with PayPal (both in terms of their operating costs and what they charge their users) is as bad as it is with creadit cards, so it really doesn't solve the micropayment problem.
Really this is just one facet of the larger issue: PayPal is just another middleman. They're a bureaucracy, which can screw the little guy just like all the other middlemen. (And if you need an example of how, just take a look at the debacle with the Webplayer co-op.)
Total PCI slots (and yes this can be important depending on your application as it translates into aggregate I/O bandwidth): GS320: 224, E10k: 64
The E10k can have more processors than the GS320, but they're not nearly as fast as the Alphas. Besides, memory bandwidth, and in parallel applications inter-processor communication (which is often just shared memory updates) is the kicker (who cares how many processors you have if they're all waiting?). The GS has more local memory bandwidth per processor and more inter-processor bandwidth than the E10k or (AFAIK) anything else.
[Yes, I work for Compaq; no, I'm not a marketroid; I'm an engineer in the Alpha microprocessor group.]
Slashdot Mirror
Well, I can't speak to the maturity of the others, but Vesta is the result of over a decade of R&D and has been in production use for microprocessor design projects at Compaq and Intel for over 6 years. Vesta's period of "trying something new" happened a long time ago, and the kinks have been worked out for years.
That's not to suggest that it's static (Intel employs two full-time software engineers to work on it), but it's been stable for a long time.
Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.
It's too bad they didn't chose something more advanced like Vesta, or Codeville, or monotone, or Darcs.
I probably should have included a link to the post I made to the git mailing list with some more details.
Of course there are some important differences. Like the fact that Vesta's been around for over a decade, and has been in production use for microprocessor design at Compaq and Intel for over 6 years.
Just to be absolutely clear: I've only ever communicated with this person on-line, and I can't verify who they are in real life or that they actually work for Comair. It seemed credible though, and it seemed worth posting to de-bunk the slashdot knee-jerk reaction of blaming Microsoft. To me, an application using a 16-bit integer for something seems like a very likely explanation.
Someone from Comair (who shall remain anonymous) provided me with some details whch people here would be interested in:
Maintainer, yes. Person who ported it to Linux and got it released as free software, yes. Author, no. (I am Ken Schalk, so I should know. :-)
Vesta was written by researchers at the Digital/Compaq Systems Research Center in Aplo Alto, CA. I've certainly tried to make a useful contribution, but I did not create it.
I can only assume you're talking about some other Vesta from the one I'm familiar with, because:
There's also Vesta, which has some pretty cool features
A couple other posts have mentioned Vesta, which goes a long way towards meeting the requirements you lay out. (For the sake of disclosure, it's only fair to mention that I am currently the primary maintainer of Vesta, and am somewhat responsible for getting it released as free software.)
Vesta absolutely does this.
Vesta does not explicitly provide this, however it's very easy to get with a simple diff command. The Vesta repository has a filesystem interface which makes it possible to directly access all versions past and present. A simple diff -r will show exactly what changed between any two versions. The also has other fun uses (e.g. greping across versions).
Vesta's access controls are essentially UNIX file permissions. Through the repository's filesystem interface, you can control who can read and write (commit new versions) at a variety of granularities with chown, chgrp, and chmod.
Vesta provides no direct help here, but again, because of the filesystem interface to the repository, it's easy to apply standalone diff/merge/conflict resolution tools.
Vesta's unit of version control is a directory. Between versions, files and subdirectories can be added, removed, renamed, etc.
Not built-in, but already implemented on top.
Vesta includes sophisticated cross-site features, including replication and remote checkout/checkin. It's been successfully applied before by a team spread across the US east and west coasts with hundreds of megabytes of sources.
Vesta really shines in these areas. Vesta is also a build tool, and every build neccessarily includes a complete specification of the set of immutable versions it uses. Builds are also themselves immutably versioned. This makes it easy to determine which source componenets have changed between two versions of a build. Also, since it's as easy to select any historical version as it is the latest one, rolling back changes is trivial.
We're still working on it (at the moment just Linux and Tru64 work), but hey, it's free software, and we'd love to have more developers/porters.
At this point there's a command-line interface and some rudimentary support for repository operations in the web interface. Again, it's free software, and we'd love to have somebody contribute more layered tools.
Nothing built-in yet, but we've been talking about doing it, and it may happen soon.
There's a short summary of Vesta's excellent capabilities on it's web site (which includes several points not mentioned here), that I would recommend anybody interested in better version control/configuration management check out.
As noted in the Inquirer's article on Vesta, it was used by the Alpha microprocessor group on the EV8 (aka Araña) project. Most of the people who used Vesta on that project are now a part of Intel, working on a future IA-64 processor. They are continuing to use Vesta under Intel.
(For the sake of disclosure, I'm one of the people who worked on that project and now work for Intel.)
I kinda figured it wouldn't take long for someone to bring up the spectre of Vesta as a Trojan and reference that classic Thompson piece.
You could certainly do what you describe. Feel free. Extract the sources from the Vesta repository, re-write the entire build description in make, and re-build. (We actually have a web interface to the repository that we're hoping to put up soon so that people can examine and even download the source without having to install Vesta.)
In fact, I challenge anyone so inclined to try and uncover any malicious code in the binaries we've released. It would be nice if someone who was not only paranoid enough but also motivated enough to follow through with that came out of the woodwork. Then perhaps we could have a better response for the next person to cast such aspersions.
We're not distributing tarballs of source for exactly the reason stated in the FAQ: you wouldn't be able to build it without writing new build instructions for make or some other builder. I don't have the time or inclination to write Makefiles to build Vesta. If somebody else wants to, that's fine, that's why its free software.
That's not the way you would use it for collaboration. The NFS interface is not intended for wide-area access, only for clients within an installation (which can be as small as one system).
The right way to use it is for each contributor to run their own Vesta repository and use Vesta's replicator to keep up to date with other repositories (such as a central master). Vesta's checkout tool automatically contacts the master repository, even if it's remote, and its checkin tool replicates the checked-in version back to the master repository.
We already have several users who work this way, one even running their Vesta repository at the other end of a 56k dialup line.
(BTW, I'm the current maintainer, the one who did much of the work of getting it ported to Linux and released.)
The love slave? No way! The most important reason to watch Lexx is Kai. That dead man in black is so dreamy!
(Sorry... I must have been channeling 790 there for a sec.)
...I'm going to Burning Man, and have been considering a project with a bunch of embedded Linux-based devices. I was trying to think of a way to power them that would neither involve a noisy gas-powered generator nor a huge quantity of batteries. (Solar cells would work during they day, but night-time operation would be essential.) This may not be the right solution considering other design constraints, but I'm going to keep it in mind.
I think a better question would be "Did they apply for their patents before the spec was published?" I honestly didn't pay enough attention in the early days of CDDB, but I'd guess that the publication of the spec pre-dates their patents. IANAL, but as patent law has been explained to me, you shouldn't be able to patent something that's been previously published. In fact, I know my company sometimes will publish papers to prevent our competitors from getting a patent on a piece of technology.
Patented material is by definition published, it just can't be used without the permission of the patent holder.
It pains me to admit it, but the market for Linux on non-x86 platforms just isn't as big. (I run Linux on Alpha, PPC, ARM, and x86 at home, Alpha nd x86 at work. Oh, and I work in the Alpha microprocessor group.)
One of the classic strengths of open source and free software is code quality improvement through peer review. The trouble is, most of the people testing and debugging are on x86. So you get better coverage, more bugs found, and more bugs fixed on x86 than on any other platform. Second tier platforms don't do as well because they have a smaller user base, and thus a smaller developer base.
In other words, support for x86 is less suceptible to bit rot, because the features get exercised more often.
Just one example is the kernel source. Virgin 2.4.3 fails to build on Alpha. (How exactly did Linus et. al. miss that?) While it built and ran on my PPC machine, it ignored keyboard and mouse input. (Aparently nobody noticed the ADB support for older machines was broken.)
Compaq literally shovels money, hardware, and other resources at RedHat to keep Alpha in its line of supported platforms. It's worth more to us to have it than it is to them.
IMHO, open source project leaders shoulds actively try to get their code tested on as many different platforms as possible. It shakes out additional bugs and improves the code. (And I don't just mean CPU architectures. If it works on x86/Linux, check it on ARM/NetBSD, Sparc/Solaris, PPC/MacOSX, and every other paltform you can get your hands on.) Unfortunately, that takes time, effort, hardware, and other resources that are usually in short supply.
But it doesn't cost money. Copying information is not the same thing as stealing a physical object, because copying takes nothing from the creator of the information. It just doesn't give them anything.
Intellectual property protection is the creation of artificial scarcity. If you don't speak Econ 101, that means it's like charging people money for breathing air. There's plenty of air, it's not a scarce resource. Information is the same, because you can make as many copies as you want without diminishing the original.
I'd suggest you take a moment and consider the reasons behind the current dispute between major drug companies and South Africa. IP protection is not a black&white issue, and it's worth questioning deeply and seriously.
I suppose we should also cry for those poor guys at Netpliance too, huh? Or how about all the people who build their houses on a flood plain?
As bandwidth and storage become cheaper (and thanks to good old Gordy Moore, they will continue to), unauthorized copying of information will become more and more common. There's just no stopping it. Eventually, most, and maybe even all business models based on charging money for copies of strings of 0s and 1s will collapse. This is just a fact of the nature of our reality. Personally I think it makes morse sense to figure out how to live in the world we're heading for, rather than jumping up and down screaming about how wrong it is.
I do. I've been working on it for several years now. The project is alive and well, and we fully intend to deliver an SMT processor. Of course delivery is still a couple years off (designing processors takes a really long time), but we'll get there eventually.
BTW, for those of you interested in SMT, we are hiring.
P.S. Great response to the nay-sayer. Wish I had written it. :-)
To me this sounds like a fabulous idea, though it's obviously not yet developed to the point of being practical for day-to-day use. And I don't think the benefits are limited to having multiple represntations of the language.
Large software systems get very hard to manipulate and understand. It becomes particularly hard to answer questions about the code. For example, given 10,000 lines of C++, do the following:
To do any of the above, you would first need to parse the code to discover its semantics and represent them in a way that you could examine in detail with a program. Writing even a simple parser is a little difficult. Parsing C++ correctly is very difficult.
Being able to directly access the true semantics of a program would make solving these kinds of problems feasible. I'm sure we can all imagine other fun things it would enable as well.
How much does it cost to recompile a piece of code after modifying the source? Basically nothing. How much does it cost to fab a new chip after modifying the design? Millions of dollars.
I'm not saying that there aren't advantages to open source hardware (and there are precedents). But the advantages aren't as big as for software because not as many people can realistically participate. Let's look at some of the classic stated advantages of open source software:
Of course if you're talking about reconfigurable computing then everything changes.
[Just in case you're wondering, I work in the Alpha mciroprocessor group at Compaq. Read into that whatever you like.]
Read the article again. They did both of these tests on exactly the same machine. Single-threaded make on a dual-processor machine is not equivalent to single-threaded make on a uni-processor. Just because make is only forking one compiler run at a time doesn't mean that there's only one task ready to execute on the machine. You can expect to get at least some improvement from parallelism between the kernel and the userspace code that's executed, and from other little things like the fact that you don't have to context switch from the compiler to the xterm process to the X server just to update the screen with the latest output.
It was a bogus test, for this and many other reasons which I won't bother repeating.
[Not that its flaws make me want one any less. This makes my Abit BP6 seem pathetic by comparison.]
Anybody running a pre-open-source Interbase seems to have only really unpleasant choices:
I'm glad I'm not in that position.
The overhead with PayPal (both in terms of their operating costs and what they charge their users) is as bad as it is with creadit cards, so it really doesn't solve the micropayment problem.
Really this is just one facet of the larger issue: PayPal is just another middleman. They're a bureaucracy, which can screw the little guy just like all the other middlemen. (And if you need an example of how, just take a look at the debacle with the Webplayer co-op.)
Why waste time drooling over one of these when you could be lamenting your lack of an AlphaServer GS320? Let's compare the two, shall we?
The E10k can have more processors than the GS320, but they're not nearly as fast as the Alphas. Besides, memory bandwidth, and in parallel applications inter-processor communication (which is often just shared memory updates) is the kicker (who cares how many processors you have if they're all waiting?). The GS has more local memory bandwidth per processor and more inter-processor bandwidth than the E10k or (AFAIK) anything else.
[Yes, I work for Compaq; no, I'm not a marketroid; I'm an engineer in the Alpha microprocessor group.]