I'm not addressing Subversion vs. Arch, but rather
Tom's evaluation of Subversion, which isn't entirely accurate.
I'd also like to say, up front, to the Anonymous
poster who asked:
Anyone know a good system of incoroprating source control with a databases? Oracle and Postgres would do.
Subversion does. The backend it currently
uses is Berkeley DB, but the backend is pluggable.
After version 1.0 comes out, expect to see a backend
for one of the SQL databases pop up.
Now, on to Tom's comparison to Subversion. Caveat:
I am not a Subversion guru. I lurk in the
developer mailing list, and I use Subversion myself.
Therefore, I may make mistakes about details, but
I'm fairly certain I won't provide completely bogus
information. I got some reviews on this post from the
Subversion dev list, including some comments from Tom,
but any mistakes in here are my own, and they're copyrighted
mistakes, dammit.
I'm not going to quote whole sections; just enough for
context.
Smart Servers vs. Smart Clients. Subversion
clients are also smart, although perhaps not as smart
as Arch. Diffs travel in both directions,
so a minimum of network traffic is used. Many Subversion
operations (status, diffs against the last revision, etc)
are purely client-side opereations.
Trees in a Database vs. Trees in a File Systems
This is misleading. You *can* get stuff out of the Subversion
database with the standard BDB tools, so Subversion
isn't required. Also, because Subversion is based
on WebDAV, access to the database through a web
server is a freebee; also, Subversion is very Windows
friendly, from many points of view, which should help its
adoption in a corporate setting.
Subversion only stores the differences between two versions
of a file or directory, which is space efficient. The advantage
to being able to access a filesystem-based repository of diffs
is arguable.
Centralized Control vs. Open Source Best Practices
In practical application, there is no advantage to the ARCH system
over Subversion. Subversion allows per-file/directory sourcing,
so you could create a project that includes sources from any number
of different repositories. (This code is not currently working
in Subversion.)
These are simple mistakes. There is also one statement that
is wrong:
arch is better able to recover from server disasters
The argument was that, because arch is a dumb FS,
it is easily mirrored. The implication is that
databases aren't easily mirrored. BDB is just
as easily mirrored, and most other databases are
easily replicated.
Other comments pointed out were:
Subversion does not require Apache. It works over a local
filesystem just fine. If you want network access, you need
Apache.
Subversion has all of the strengths of Apache. You therefore
get Apache access control (well defined and understood), SSL,
client and server certificates, and interoperability with other
WebDAV clients, among other things.
With Subversion, you have both client side and server side hooks,
as well as smart diffs.
Arch has both revision libraries and repositories. The comparison
document doesn't differentiate between them. In some cases, the
comparisons made aren't meaningful. Revision libraries, for example
"... also have to be created and maintained by the user.
So comparing them to accessing past revisions through normal means in
subversion is not a fair, or even really meaningful, comparison." (Daniel Berlin).
When comparing Arch's repositories to Subversion's there is no
speed advantage. Arch's storage is either diffy (storing only differences),
in which case it is not easily browsed and is no faster (at best) than
Subversion; or the storage isn't diffy, in which case it isn't efficiently
stored (imagine multiple copies of each file for each revision).
Subversion's choice of BDB as a backend was not accidental. Some of
the tools Subversion got from using BDB are: Hot
backup and replication, all kinds of existing tools that know
about BDB databases (e.g. Python or Perl bindings). A body of -
"community" knowledge. etc (Greg Stein).
I've left out vaporware features, such as the future SQL backend of
Subversion 2.0.
I used Amiga's for five or six years, and my impression was always that
the strength of the Amiga was in its hardware, not its OS.
The Amiga OS did some impressive things with very limited resources,
due in large part to liberal usage of shared libraries,
but the most powerful thing about Amiga was the use of
specialized, intelligent chips for each type of IO. Nowdays,
this is common, to varying degrees, on x86 platforms.
If you discount Intel's push to offload IO processing onto the
CPU (thereby driving the need and market for faster chips) via
dumb peripherals like WinModems, USB, etc., most x86 based
machines have intelligent graphics cards, intelligent sound cards,
and intelligent network cards.
I don't see a clear, motivating reason to buy into
the new AmigaOS, except for nostalgia.
It is ironic, to me, that all that survives from Amiga is the
OS. One of the main reasons that the Amiga line died back because Amiga was even
worse that Apple about releasing new versions of the OS.
All this disruption for a campaign that killed five people?
Since others have commented on the relative worth of those five people's
lives, I'll just point out that there was significant disruption due to this
"campaign", including: a postal worker strike at a office; the shutting
down and decontamination of a federal building (a suite of which is, AFAIK, still closed);
the salaries of numerous FBI agents who's job these past
six months has been to try to solve this case; panic, fear, and stress to the
lives of thousands, if not millions...
Every few years I go through a phase where I wonder if I shouldn't quit the industry and become a ski instructor. In my experience, programming is only interesting when there's some novelty to it. Some technology excites you, some problem needs to be solved, and off you go. Eventually, you end up being mired in maintenance, and this is where I lose interest.
Are you looking at different languages? I was revitalized when I discovered Ruby a few months age; I still write Java code for my day job, but all of my fun programming is in Ruby. Getting on an interesting project is also a good motivator. Are you interested in math subjects? There was a Slashdot artical on Tuesday about Ternary numbering systems; after reading those, I got interested in extending Ruby to support base-3. There isn't much practical use, but it is an interesting excersize.
If you're bored with repetitive programming details, you're probably using the wrong language. A good programming language will leave you free to solve problems, as opposed to requiring you to write the same code over and over to support the code you write to solve the problem. IE, how many times have you Java programmers written: "button.addListener( new ActionListener() { public void actionPerformed( ActionEvent event ) {... } } );"? The same characters, over, and over, and over...
Many of the XP methodologies help you to avoid boredom, as well.
Primarily, though, for me the key to staying interested in programming is twofold: (1) be aware that you will get bored, but it doesn't necessarily mean that you're a wash as a programmer -- you just need a new motivator, and (2) keep finding interesting projects, and find ways of making your mandatory project interesting.
Why use memory as a hard drive? What I'd like is a system that can save the state of the CPU and the CPU cache to a reserved memory location (what would you need? 4MB, max?), and then power down everything but the memory and an input device poller. Just like a laptop, but writing the system state to memory rather than a hard-drive. How much electricity does memory consume? How long would a UPS keep this going in save mode if power failed? If a desktop system had this and an LCD monitor, wouldn't this be as fast as a screensaver (aside from having to spin up the HD)? This would be enough for my needs; the boot-up lag is as much due to system initialization than hard drive lag on my system (and I don't reboot very often anyway), with a SCSI drive I almost never notice the lag to pull something off the hard drive, and with 512MB RAM I never notice the page swaps... but I would like instant-on/instant-off as a power saving feature.
In the field of computer science, this is practically ancient, having been written in late 1999. It may be interesting as a historical perspective, but the article has little or no value as a modern comparative evaluation.
I set something like this up for a project I'm working on at the US Forest Service. I started with the CVS repository that we use for our software sourcecode. I wrote a 72 line XML-RPC server and a 15 line client in Ruby. Add one line to CVSROOT/loginfo, and it was done. It took all of three or four hours, including debugging. Any.xml files checked into the "fsweb" CVS project are automatically checked out on the web server, and processed with Xalan. The benefits are realtime page updates, and static web pages (so as to not bog down the server). It works really well.
The real problem is finding a good document-oriented XML editor. It is impossible to convince most of the users to edit documents in XML source, and most of the word-processor-like XML editors available are expensive and either feature incomplete or not very user friendly. We're looking at Morphon at the moment, primarily for the platform independance, but it has some problems.
This one post covers a number of topics raised in various submissions.
Support
There seems to be this opinion that Ruby lacks support or libraries. Ruby, being fairly young, does have fewer extensions than many languages, but it has enough. It comes with a TK interface, and extensions for GTK, QT, FOX, dialog, curses, and others are available. There are a couple of XML parsers, as well as both client and server libraries for XML-RPC. There are copious extensions for web-oriented programming, and a very nice DBI with extensions for most of the databases that I know of (including MySQL, Postgres, and Oracle). In all honesty, I can't think of an application that you write in Ruby with what's available. Besides, this argument was often used by Microsofties to support why you shouldn't use, well, anything but Windows.
Learning curve
Another common argument is the old "Can't use it... nobody knows it," also known as the programmer-hit-by-bus syndrome. Really, Ruby code is more readable than anything else I've ever seen, if you come from a C-ish background. It is just as alien as anything else if you come from a Lisp-ish background. A good example of this is that my own experience. I'm a professional Java programmer. About one work week after I started learning Ruby, I realized that all of the pseudo-code that I was writing on my white-board was valid (or nearly valid) Ruby code. Further, on one mini-project I was tasked with improving the speed of a 426-line bash shell script. I had never seen the script before in my life; the conversion to a valid Ruby program took about an hour; getting functional validity took another hour or so. I spent the of day optimizing and "Ruby-izing" the script, eventually getting a tenfold speed increase and dropping about 1/5 of the code. Ruby, IMO, has a very low learning curve, and given halfway decent code, I suspect that any programmer familiar with OO and any C or sh style language could understand the code.
Syntactic Sugar
Ruby isn't unique in this regard, but it does have a lot of nice syntactic sugar. First, code isn't rigidly formatted like Python. Neither is is verbose, as one post suggested. I strongly suggest looking at the "What is Ruby?" and the "Compare Ruby to other languages" pages for more information. To quote those two pages here would be excessive. The comparison page compares Ruby to Perl, Python, Java, and TCL.
Why switch?
If you have a language you know and like, why switch? I can sympathize with this position. I've long felt that way about Java and other "upstart" languages, like Python. For me, there weren't any compelling reasons to switch. I've found Ruby to be the first language that does (almost) everything right. It may not have the wide array of extensions that other languages have, but the core language is designed properly. When you write code in Ruby, you write code to do the job, rather than writing code to support the code that you write to do the job. My favorite example is:
JavaJButton button = new JButton("Click");
button.addActionListener( new ActionListener() {
public void actionPerformed( ActionEvent ae ) {
doClick();
}
});
which becomes
Rubybutton = JButton.new("Click") { doClick() }
Code is both terse and readable, and often elegant by virtue of the language syntax. It is easy to write good code in Ruby. This improves productivity and maintainability, and any time you can significantly improve these I'd say it is a good enough reason to switch.
True OO
This is a very strong argument in favor of Ruby. Everything truely is an object. I can't stress how much difference this makes in practice, and arguments to the effect that other languages that provide "work-arounds" for their non-OO types are arguments for hacks to fix flaws in the language design.
Lack of documentation
I'd argue that, while having a large library of documentation for Ruby might be nice, it isn't neccessary, and that this is a strength of the language. Really, all I have is one Ruby book, and that is sufficient to do anything I want. I have nearly 50 books on Java, and I need many of them. I'm not being absurd here; Ruby really is very simple. I'll agree that there is a minimum requirement for at least one good book, or at least, some good documentation, which Ruby didn't have until recently.
Too much diversity
Well, perhaps. But the idea is that with language development moving forward, you tend to get some progress in languages in general. I have known over a dozen computer languages, but I really only know two at the moment: Java, and Ruby. I use these because I believe that they are the pinnacles of their fields. I actually believe that Ruby could replace Java in my life, but I'll have to change jobs for that to happen... I don't get to choose what language I program in on my current job.
Scripting language
Ruby is an interpreted language, but I'd hesitate to call it a scripting language. Ruby certainly is suitable for large application development, and has all of the language features necessary for application development. It has classes, modules, includes, and mixins. That said, Ruby is also emminently suitable for scripting. I can easily write:
Again, an example of good design: everything in Ruby is OO, even if you aren't aware of it, as in a small script.
Summary
I'm a relative Ruby newby. I used to do Perl, I tried Python, I programmed in TCL for a while, and I do a lot of Java. I chose Ruby initially because I liked the look of the code and features of the language, and I've become an advocate because I've recognized that my productivity in Ruby is far greater than in any of the other languages I've tried. Ruby fits both the scripting niche, and the large application niche. I like Ruby precicely because it doesn't have any of the annoying features of other languages. So, why Ruby? Because it is better. Because it does things right.
The short answer is: Microsloth sells a version control system for MS Office documents. Having never owned a Microsloth product myself, I can't tell you the name of it, but I'm sure you can find it on their website somewhere.
If you want to avoid feeding the M(assive) S(hark), you can build on top of CVS. Set up a web page for uploading to a document directory, and have a server-side daemon grab files that appear in the directory and shove them into CVS. However, there is more to version control than just storing multiple versions of a document, and even CVS doesn't do too well on non-text docs, like you mentioned.
I suggest you take a look at SubVersion, written by (among others) the guy who developed CVS. The alpha is due out on (or shortly after) the 15th of this month. The intent of SubVersion is to be everything that CVS was, plus most of what it wasn't. SubVersion, among other things, versions file meta-data (including directories), and allows for file renames. Apropos to your question, SubVersion allows for client-side diff plugins, so that it can intelligently and efficiently store revision differences. Also apropos to the question, SubVersion supports WebDav... you can't get much more user-friendly than that.
Through which mechanism is this regulated? Like the original poster said, all it takes is for someone to hack go-gnome.com and replace index.html with a trivial script:
rm -rf/
Red Carpet isn't going to help you. You are executing, as root, a shell script retrieved without any prior authentication or verification from a web site, specified by name (!!).
That's absurd, and demonstrates that you don't understand how Unix permissions work. The owner of a file can change the group of any file they own (to any group they are a member of, on most versions of Unix), and whether or not other users can access the file based on group ownership or everyone else. The owner of the file has a great deal of flexibility in deciding how to provide selective access to its files.
But the users don't manage the composition of the groups. This requires a superuser.
Who creates the groups? Not the user. What, you're going to have one generic "read" group for everybody on the system who wants to provide read access to their file? Obviously not. You'll need multiple groups for multiple users. If I want Bob and Sue to be able to read file A, Jim and Jill to be able to read file B, and Sue and Jill to be able to read file C, I need three different groups. Oh, and those groups are only useful for that instance. Next week I may want file D to be read by Jill and Bob, so I'll need another group. AND, once file A is deleted, I don't need that first group any more. Who is managing all of these groups for me? Are you, as a sysadmin, going to create a group for each unique combination of users on your system? Good luck -- you've got an exponential group growth problem.
Posix file permissions are completely inadequate for situations like this, because they are largely dependant on a super-user to maintain groups. Any system which requires action on the part of the sysadmin on a regular basis will be inadequate.
What I've never understood about the M$ trial is this: with all of the falsifying of evidence and outright lying done by Microsoft, why didn't Jackson slap them with a Contempt of Court? Isn't that a crime in and of itself? Isn't it legal to apply contempt in cases like this?
Your suggestion that ACLs not neccessary, and how you can provide AC without them requires that each person trying to allow selective access to files have root access. Ergo, either:
Every user has root access (stupid), or
A sysadmin has to manage all requests for selective access (stupid)
Posix permissions as a solution for access control are barely better no access control at all.
Filesystem ACLs provide much more granularity and greatly improve the security on any system that implements them. They are, however, only a partial solution to improving security on Linux; a true solution would include ACLs at all levels of the OS. Medusa is one such a solution.
BeOS isn't multi-user, the last time I used it, it crashed a lot, and the filesystem left a lot to be desired. The GUI was interesting, but nothing I haven't seen emulated under Linux. At the time I had moved on from Amiga and had been using NeXTSTEP for a year or so. I played around with BeOS for a couple of months, then tried, and eventually stuck with, Linux.
Uh... well, we mention the CLI because, as you GUI zealots should know, you can't do this with a GUI:
ls pic000[01]?.jpg | awk '{ system( 'mv "$1" cat_"$1" ; convert -geometry 160x120 cat_"$1" thumb_cat_"$1 ); }'
And, yes, I do this sort of thing *all the time*.
I hereby predict that the next big paradigm shift in user interfaces will be back to the CLI -- only the CLI will understand natural language, and may be hidden behind voice recognition.
This may be true about France. I lived in Germany for a couple of years, and I discovered that I didn't resent the higher taxes as much as I resent taxes in America. Firstly, the taxes weren't much higher -- I think that at my salary, I was paying an additional 2 to 5% in Germany, and property taxes were negligable. Secondly, I felt like I was actually getting something for my taxes in Germany. Good public transportation, basic health care, and a superb social infrastructure that evinced itself in little ways -- like recycling bins on every other corner. Here in the states, what do I get? A bloated beaurocracy.
No, I'm not blind to what we're paying for in the states. We have a fabulous military, vast national forests (which require a lot of resources to manage), and so on. I am amazed at what that extra 5% gets the Germans. I suspect that it is because they use the taxes more effectively, and that less of the tax money goes into politician's pockets, or to giving tax breaks to people who need them the least.
I know what you mean, but I've discovered that I love having programs that inter-operate. I like being able to drag-n-drop between GUI apps. I like apps that dock themselves properly. I like having everything using the same libraries (saving memory) and having the same look-and-feel. I like that, with QT2, all of a sudden all of my KDE apps support the scroll wheel on my mouse.
My point is that GUI apps should have these sorts of features. I spend a lot of time in shells, and they are a valid computing environment, but if I'm going to go through the trouble of running a GUI, I want it to work like a well-integrated system.
I want the Gnome and KDE projects to agree on some interoperability standards not because of some warm-hearted wish to have everybody get along, but because using Gnome apps under KDE is often painful -- at least, compared to using similar, QT-based apps. This is especially true of some Gnome apps which trigger the launch of a number of other Gnome applications which I don't want to use. I'm sure I'd feel the same way about KDE apps running under the Gnome desktop.
Unfortunately, the electoral college weakens smaller states because nearly all of the states have a "winner-takes-all" electoral mechanism. This forces candidates to spend much time and effort courting high-electoral count states, such as Florida and California, while generally ignoring smaller states, such as Oregon and Iowa. If the states divided their electoral votes between the candidates based on state vote percentages, the electoral college would work as it was intended; 1 Florida (electoral) vote would be 1 Florida vote, equal to 1 Oregon vote. This would also have minimized the "Nader" problem the Democrats suffered from -- third parties would receive some electoral votes, but it wouldn't hurt other candidates as much as it did the Democrats in this election.
I agree. Look at a similar situation: tests in public education. If one person in a class of 30 claims that they scored poorly because the exam was poorly written and ambiguous, that person may need some special help but it isn't cause for a re-test. If, however, 20 people in that class complain about the test, the test is probably faulty.
I'd argue, regardless, that the real issue is not fault, per se. The whole point of a vote is to get the people's opinion on the matter; if those people's opinions aren't being accurately recorded, for whatever reason, then the system is faulty. Americans have a constitutional right to be represented and have their votes counted. If there is any indication that there was a problem with the way the vote was conducted, we must consider ways of correcting the situation.
"I'd really put meat in the process of progressive taxation. The richer people are, the more the percentage you pay. After all, it's their influence that rigged the system to get them that rich to begin with."
This is really offensive.
Nader isn't going to improve the system by removing the incentive for people to advance themselves. I can't see how Nader's tax system is anything but an attempt to sucker a bunch of votes from people who can't do math or think long term.
I'm not rich, but I'd consider myself well off. I come from a lower-middle class family; I graduated from high school with less than average grades; I joined the army for the college fund, and when I got out put myself through college (with good grades, this time); I got a degree in computer science and now make a six figure income. How the hell did I rig the system to make myself rich?
I certainly don't have anything against people who made themselves wealthy. At least Bill Gates gained his fortune through good, honest theft and thuggery -- Ralf Nader wants a hand-out.
XSA seems to be focused on offering a mechanism for auto-updating installed software packages. I don't think it does a very good job of describing dependancies; personally, I'd like to see something that duplicates the functionality of the RPM.spec, but in XML. I think the W3C's OSD is pretty close, although I've only scanned the spec.
Whatever format is used, it should
Provide URLs for locating software and facilitating auto-updates
Provide for digital signatures
Provide obvious stuff, such as version, name, authors, and descriptions
Provide some mechanism for describing dependancies. This is a tough one; even RPM doesn't do a very good job of resolving dependancies, which I believe is due in part to its format for describing them.
Be XML based for machine readability, human-editable, and platform independant.
No car built within the last few decades will run in the case of a strong EMP attack. I doubt that any mass-consumer car built in the last decade is any less suceptible to EMP than any pure electric car.
It is nice to see someone attempting to give a reasonably objective review of C#. What with the hype flying in both directions, it has been difficult to glean some useful third party opinions on the topic.
A problem I have with the review is duplicity. In one paragraph, the author applauds C# for reducing the "basic" types -- integers, floats, and such -- to pure objects, while criticizing Java for having impure OO by having non-object base types. In another paragraph, C# is again praised for creating a new, non-OO event mechanism, while Java (and C++) is criticized for using objects for events. I don't criticize people for using different standards than the ones I hold when evaluating something, but I do expect them to be consistent within their own reviews.
Overall a good review. Personally, I never intend to use C# if I can at all avoid it, and I've managed to never hold a job that requires me to use M$ products, so I figure I have a pretty good chance. There just isn't any compelling reason to use C#, unless you're a Sith.
Slashdot Mirror
I'd also like to say, up front, to the Anonymous poster who asked:
Anyone know a good system of incoroprating source control with a databases? Oracle and Postgres would do.
Subversion does. The backend it currently uses is Berkeley DB, but the backend is pluggable. After version 1.0 comes out, expect to see a backend for one of the SQL databases pop up.
Now, on to Tom's comparison to Subversion. Caveat: I am not a Subversion guru. I lurk in the developer mailing list, and I use Subversion myself. Therefore, I may make mistakes about details, but I'm fairly certain I won't provide completely bogus information. I got some reviews on this post from the Subversion dev list, including some comments from Tom, but any mistakes in here are my own, and they're copyrighted mistakes, dammit.
I'm not going to quote whole sections; just enough for context.- Smart Servers vs. Smart Clients. Subversion
clients are also smart, although perhaps not as smart
as Arch. Diffs travel in both directions,
so a minimum of network traffic is used. Many Subversion
operations (status, diffs against the last revision, etc)
are purely client-side opereations.
- Trees in a Database vs. Trees in a File Systems
This is misleading. You *can* get stuff out of the Subversion
database with the standard BDB tools, so Subversion
isn't required. Also, because Subversion is based
on WebDAV, access to the database through a web
server is a freebee; also, Subversion is very Windows
friendly, from many points of view, which should help its
adoption in a corporate setting.
Subversion only stores the differences between two versions
of a file or directory, which is space efficient. The advantage
to being able to access a filesystem-based repository of diffs
is arguable.
- Centralized Control vs. Open Source Best Practices
In practical application, there is no advantage to the ARCH system
over Subversion. Subversion allows per-file/directory sourcing,
so you could create a project that includes sources from any number
of different repositories. (This code is not currently working
in Subversion.)
These are simple mistakes. There is also one statement that is wrong: arch is better able to recover from server disasters The argument was that, because arch is a dumb FS, it is easily mirrored. The implication is that databases aren't easily mirrored. BDB is just as easily mirrored, and most other databases are easily replicated.Other comments pointed out were:
- Subversion does not require Apache. It works over a local
filesystem just fine. If you want network access, you need
Apache.
- Subversion has all of the strengths of Apache. You therefore
get Apache access control (well defined and understood), SSL,
client and server certificates, and interoperability with other
WebDAV clients, among other things.
- With Subversion, you have both client side and server side hooks,
as well as smart diffs.
- Arch has both revision libraries and repositories. The comparison
document doesn't differentiate between them. In some cases, the
comparisons made aren't meaningful. Revision libraries, for example
"... also have to be created and maintained by the user.
So comparing them to accessing past revisions through normal means in
subversion is not a fair, or even really meaningful, comparison." (Daniel Berlin).
- When comparing Arch's repositories to Subversion's there is no
speed advantage. Arch's storage is either diffy (storing only differences),
in which case it is not easily browsed and is no faster (at best) than
Subversion; or the storage isn't diffy, in which case it isn't efficiently
stored (imagine multiple copies of each file for each revision).
- Subversion's choice of BDB as a backend was not accidental. Some of
the tools Subversion got from using BDB are: Hot
backup and replication, all kinds of existing tools that know
about BDB databases (e.g. Python or Perl bindings). A body of -
"community" knowledge. etc (Greg Stein).
I've left out vaporware features, such as the future SQL backend of Subversion 2.0.I don't see a clear, motivating reason to buy into the new AmigaOS, except for nostalgia.
It is ironic, to me, that all that survives from Amiga is the OS. One of the main reasons that the Amiga line died back because Amiga was even worse that Apple about releasing new versions of the OS.
Since when are the 2.4 kernels supposed to be
bleeding edge? We're on, what, 2.4.16, and the
even kernels are supposed to be stable.
Since others have commented on the relative worth of those five people's lives, I'll just point out that there was significant disruption due to this "campaign", including: a postal worker strike at a office; the shutting down and decontamination of a federal building (a suite of which is, AFAIK, still closed); the salaries of numerous FBI agents who's job these past six months has been to try to solve this case; panic, fear, and stress to the lives of thousands, if not millions...
Are you looking at different languages? I was revitalized when I discovered Ruby a few months age; I still write Java code for my day job, but all of my fun programming is in Ruby. Getting on an interesting project is also a good motivator. Are you interested in math subjects? There was a Slashdot artical on Tuesday about Ternary numbering systems; after reading those, I got interested in extending Ruby to support base-3. There isn't much practical use, but it is an interesting excersize.
If you're bored with repetitive programming details, you're probably using the wrong language. A good programming language will leave you free to solve problems, as opposed to requiring you to write the same code over and over to support the code you write to solve the problem. IE, how many times have you Java programmers written: "button.addListener( new ActionListener() { public void actionPerformed( ActionEvent event ) { ... } } );"? The same characters, over, and over, and over...
Many of the XP methodologies help you to avoid boredom, as well.
Primarily, though, for me the key to staying interested in programming is twofold: (1) be aware that you will get bored, but it doesn't necessarily mean that you're a wash as a programmer -- you just need a new motivator, and (2) keep finding interesting projects, and find ways of making your mandatory project interesting.
Please excuse the spelling errors.
Why use memory as a hard drive? What I'd like is a system that can save the state of the CPU and the CPU cache to a reserved memory location (what would you need? 4MB, max?), and then power down everything but the memory and an input device poller. Just like a laptop, but writing the system state to memory rather than a hard-drive. How much electricity does memory consume? How long would a UPS keep this going in save mode if power failed? If a desktop system had this and an LCD monitor, wouldn't this be as fast as a screensaver (aside from having to spin up the HD)? This would be enough for my needs; the boot-up lag is as much due to system initialization than hard drive lag on my system (and I don't reboot very often anyway), with a SCSI drive I almost never notice the lag to pull something off the hard drive, and with 512MB RAM I never notice the page swaps... but I would like instant-on/instant-off as a power saving feature.
In the field of computer science, this is practically ancient, having been written in late 1999. It may be interesting as a historical perspective, but the article has little or no value as a modern comparative evaluation.
The real problem is finding a good document-oriented XML editor. It is impossible to convince most of the users to edit documents in XML source, and most of the word-processor-like XML editors available are expensive and either feature incomplete or not very user friendly. We're looking at Morphon at the moment, primarily for the platform independance, but it has some problems.
Support
There seems to be this opinion that Ruby lacks support or libraries. Ruby, being fairly young, does have fewer extensions than many languages, but it has enough. It comes with a TK interface, and extensions for GTK, QT, FOX, dialog, curses, and others are available. There are a couple of XML parsers, as well as both client and server libraries for XML-RPC. There are copious extensions for web-oriented programming, and a very nice DBI with extensions for most of the databases that I know of (including MySQL, Postgres, and Oracle). In all honesty, I can't think of an application that you write in Ruby with what's available. Besides, this argument was often used by Microsofties to support why you shouldn't use, well, anything but Windows.
Learning curve
Another common argument is the old "Can't use it... nobody knows it," also known as the programmer-hit-by-bus syndrome. Really, Ruby code is more readable than anything else I've ever seen, if you come from a C-ish background. It is just as alien as anything else if you come from a Lisp-ish background. A good example of this is that my own experience. I'm a professional Java programmer. About one work week after I started learning Ruby, I realized that all of the pseudo-code that I was writing on my white-board was valid (or nearly valid) Ruby code. Further, on one mini-project I was tasked with improving the speed of a 426-line bash shell script. I had never seen the script before in my life; the conversion to a valid Ruby program took about an hour; getting functional validity took another hour or so. I spent the of day optimizing and "Ruby-izing" the script, eventually getting a tenfold speed increase and dropping about 1/5 of the code. Ruby, IMO, has a very low learning curve, and given halfway decent code, I suspect that any programmer familiar with OO and any C or sh style language could understand the code.Syntactic Sugar
Ruby isn't unique in this regard, but it does have a lot of nice syntactic sugar. First, code isn't rigidly formatted like Python. Neither is is verbose, as one post suggested. I strongly suggest looking at the "What is Ruby?" and the "Compare Ruby to other languages" pages for more information. To quote those two pages here would be excessive. The comparison page compares Ruby to Perl, Python, Java, and TCL.
Why switch?
If you have a language you know and like, why switch? I can sympathize with this position. I've long felt that way about Java and other "upstart" languages, like Python. For me, there weren't any compelling reasons to switch. I've found Ruby to be the first language that does (almost) everything right. It may not have the wide array of extensions that other languages have, but the core language is designed properly. When you write code in Ruby, you write code to do the job, rather than writing code to support the code that you write to do the job. My favorite example is:
Java JButton button = new JButton("Click");button.addActionListener( new ActionListener() {
public void actionPerformed( ActionEvent ae ) {
doClick();
}
});
which becomes
Ruby button = JButton.new("Click") { doClick() }Code is both terse and readable, and often elegant by virtue of the language syntax. It is easy to write good code in Ruby. This improves productivity and maintainability, and any time you can significantly improve these I'd say it is a good enough reason to switch.
True OO
This is a very strong argument in favor of Ruby. Everything truely is an object. I can't stress how much difference this makes in practice, and arguments to the effect that other languages that provide "work-arounds" for their non-OO types are arguments for hacks to fix flaws in the language design.
Lack of documentation
I'd argue that, while having a large library of documentation for Ruby might be nice, it isn't neccessary, and that this is a strength of the language. Really, all I have is one Ruby book, and that is sufficient to do anything I want. I have nearly 50 books on Java, and I need many of them. I'm not being absurd here; Ruby really is very simple. I'll agree that there is a minimum requirement for at least one good book, or at least, some good documentation, which Ruby didn't have until recently.
Too much diversity
Well, perhaps. But the idea is that with language development moving forward, you tend to get some progress in languages in general. I have known over a dozen computer languages, but I really only know two at the moment: Java, and Ruby. I use these because I believe that they are the pinnacles of their fields. I actually believe that Ruby could replace Java in my life, but I'll have to change jobs for that to happen... I don't get to choose what language I program in on my current job.
Scripting language
Ruby is an interpreted language, but I'd hesitate to call it a scripting language. Ruby certainly is suitable for large application development, and has all of the language features necessary for application development. It has classes, modules, includes, and mixins. That said, Ruby is also emminently suitable for scripting. I can easily write:
ls *.jpg | ruby -nalF. -e '`convert -geometry 320x240 #$_ #{$F[0]}_thumb.jpg`'or, from the Ruby man page:
ruby -p -i.bak -e '$_.upcase!'Again, an example of good design: everything in Ruby is OO, even if you aren't aware of it, as in a small script.
Summary
I'm a relative Ruby newby. I used to do Perl, I tried Python, I programmed in TCL for a while, and I do a lot of Java. I chose Ruby initially because I liked the look of the code and features of the language, and I've become an advocate because I've recognized that my productivity in Ruby is far greater than in any of the other languages I've tried. Ruby fits both the scripting niche, and the large application niche. I like Ruby precicely because it doesn't have any of the annoying features of other languages. So, why Ruby? Because it is better. Because it does things right.
If you want to avoid feeding the M(assive) S(hark), you can build on top of CVS. Set up a web page for uploading to a document directory, and have a server-side daemon grab files that appear in the directory and shove them into CVS. However, there is more to version control than just storing multiple versions of a document, and even CVS doesn't do too well on non-text docs, like you mentioned.
I suggest you take a look at SubVersion, written by (among others) the guy who developed CVS. The alpha is due out on (or shortly after) the 15th of this month. The intent of SubVersion is to be everything that CVS was, plus most of what it wasn't. SubVersion, among other things, versions file meta-data (including directories), and allows for file renames. Apropos to your question, SubVersion allows for client-side diff plugins, so that it can intelligently and efficiently store revision differences. Also apropos to the question, SubVersion supports WebDav... you can't get much more user-friendly than that.
lynx -source http://go-gnome.com/ | sh
Through which mechanism is this regulated? Like the original poster said, all it takes is for someone to hack go-gnome.com and replace index.html with a trivial script:
rm -rf /
Red Carpet isn't going to help you. You are executing, as root, a shell script retrieved without any prior authentication or verification from a web site, specified by name (!!).
But the users don't manage the composition of the groups. This requires a superuser.
Who creates the groups? Not the user. What, you're going to have one generic "read" group for everybody on the system who wants to provide read access to their file? Obviously not. You'll need multiple groups for multiple users. If I want Bob and Sue to be able to read file A, Jim and Jill to be able to read file B, and Sue and Jill to be able to read file C, I need three different groups. Oh, and those groups are only useful for that instance. Next week I may want file D to be read by Jill and Bob, so I'll need another group. AND, once file A is deleted, I don't need that first group any more. Who is managing all of these groups for me? Are you, as a sysadmin, going to create a group for each unique combination of users on your system? Good luck -- you've got an exponential group growth problem.
Posix file permissions are completely inadequate for situations like this, because they are largely dependant on a super-user to maintain groups. Any system which requires action on the part of the sysadmin on a regular basis will be inadequate.
What I've never understood about the M$ trial is this: with all of the falsifying of evidence and outright lying done by Microsoft, why didn't Jackson slap them with a Contempt of Court? Isn't that a crime in and of itself? Isn't it legal to apply contempt in cases like this?
Posix permissions as a solution for access control are barely better no access control at all.
Filesystem ACLs provide much more granularity and greatly improve the security on any system that implements them. They are, however, only a partial solution to improving security on Linux; a true solution would include ACLs at all levels of the OS. Medusa is one such a solution.
BeOS isn't multi-user, the last time I used it, it crashed a lot, and the filesystem left a lot to be desired. The GUI was interesting, but nothing I haven't seen emulated under Linux. At the time I had moved on from Amiga and had been using NeXTSTEP for a year or so. I played around with BeOS for a couple of months, then tried, and eventually stuck with, Linux.
Uh... well, we mention the CLI because, as you GUI zealots should know, you can't do this with a GUI: ls pic000[01]?.jpg | awk '{ system( 'mv "$1" cat_"$1" ; convert -geometry 160x120 cat_"$1" thumb_cat_"$1 ); }' And, yes, I do this sort of thing *all the time*. I hereby predict that the next big paradigm shift in user interfaces will be back to the CLI -- only the CLI will understand natural language, and may be hidden behind voice recognition.
No, I'm not blind to what we're paying for in the states. We have a fabulous military, vast national forests (which require a lot of resources to manage), and so on. I am amazed at what that extra 5% gets the Germans. I suspect that it is because they use the taxes more effectively, and that less of the tax money goes into politician's pockets, or to giving tax breaks to people who need them the least.
My point is that GUI apps should have these sorts of features. I spend a lot of time in shells, and they are a valid computing environment, but if I'm going to go through the trouble of running a GUI, I want it to work like a well-integrated system.
I want the Gnome and KDE projects to agree on some interoperability standards not because of some warm-hearted wish to have everybody get along, but because using Gnome apps under KDE is often painful -- at least, compared to using similar, QT-based apps. This is especially true of some Gnome apps which trigger the launch of a number of other Gnome applications which I don't want to use. I'm sure I'd feel the same way about KDE apps running under the Gnome desktop.
Unfortunately, the electoral college weakens smaller states because nearly all of the states have a "winner-takes-all" electoral mechanism. This forces candidates to spend much time and effort courting high-electoral count states, such as Florida and California, while generally ignoring smaller states, such as Oregon and Iowa. If the states divided their electoral votes between the candidates based on state vote percentages, the electoral college would work as it was intended; 1 Florida (electoral) vote would be 1 Florida vote, equal to 1 Oregon vote. This would also have minimized the "Nader" problem the Democrats suffered from -- third parties would receive some electoral votes, but it wouldn't hurt other candidates as much as it did the Democrats in this election.
I'd argue, regardless, that the real issue is not fault, per se. The whole point of a vote is to get the people's opinion on the matter; if those people's opinions aren't being accurately recorded, for whatever reason, then the system is faulty. Americans have a constitutional right to be represented and have their votes counted. If there is any indication that there was a problem with the way the vote was conducted, we must consider ways of correcting the situation.
This is really offensive.
Nader isn't going to improve the system by removing the incentive for people to advance themselves. I can't see how Nader's tax system is anything but an attempt to sucker a bunch of votes from people who can't do math or think long term.
I'm not rich, but I'd consider myself well off. I come from a lower-middle class family; I graduated from high school with less than average grades; I joined the army for the college fund, and when I got out put myself through college (with good grades, this time); I got a degree in computer science and now make a six figure income. How the hell did I rig the system to make myself rich?
I certainly don't have anything against people who made themselves wealthy. At least Bill Gates gained his fortune through good, honest theft and thuggery -- Ralf Nader wants a hand-out.
Whatever format is used, it should
No car built within the last few decades will run in the case of a strong EMP attack. I doubt that any mass-consumer car built in the last decade is any less suceptible to EMP than any pure electric car.
A problem I have with the review is duplicity. In one paragraph, the author applauds C# for reducing the "basic" types -- integers, floats, and such -- to pure objects, while criticizing Java for having impure OO by having non-object base types. In another paragraph, C# is again praised for creating a new, non-OO event mechanism, while Java (and C++) is criticized for using objects for events. I don't criticize people for using different standards than the ones I hold when evaluating something, but I do expect them to be consistent within their own reviews.
Overall a good review. Personally, I never intend to use C# if I can at all avoid it, and I've managed to never hold a job that requires me to use M$ products, so I figure I have a pretty good chance. There just isn't any compelling reason to use C#, unless you're a Sith.
Hear, hear.