Somebody hit this judge with a clue-stick please?
It would be a lot easier to try to end the use of Madster by left handed people while allowing right handed to continue using the system.
I think you're not giving the judge enough credit. It's likely that he knows that. He's requiring the companies suing Madster to come up with a way to avoid harming innocent users before he takes any action. If they can't, he might make them demonstrate thoroughly that virtually no one uses the system in a legitimate way. If they can't do either, sucks for them.
Somone probably thought this was a great deep and meaningfull peice of modern art...but blahh. Big deal.
I modded this down because I thought your comment was baseless, but then I saw this a couple links away from their counter:
a moment in the web. alpha 3.5 is a webserver (click here for the server specs) which will crush itself, on 12 septmeber 1900 hours GMT.Although the act of crushing/destroying the computer suggests a Neo-Luddite reaction towards technology, it is only one facet of the work. The act of destroying the server brings up an interesting proposition: the physicality of the 'internet'. When the client computer fails to find the data from the server, the browser has an error - "cannot find server - xx", and a list of instructions, and reasons appears to rectify the problem. Interestingly, we know the reason why the server cannot be found but the client computer does not. This brings out another aspect of the internet: the physical relationship between the server and the client. Only when the data/server does not exist or fails to function, then the internet user is reminded of this relationship.
They seem to think it's deep but indeed it's just dumb...
As someone said, the idea is to make it as easy as possible, but no easier. Currently, a lot of time is wasted with trivial stuff. Of course, you will have to think a lot about the network and filesystem options. However, there are lot of options that should be selected by default too.
Okay, requiring less time, not less skill, seems like a reasonable goal. But also a completely different one than you gave in your first post.
Again, average users don't need to recompile the kernel. Concessions to their lack of technical expertise would be ineffective and unnecessary.
It is almost as important to lower the barrier of entry for kernel hacking, which is very important for Linux's vitality. And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
That wouldn't lower the barrier of entry for kernel hacking. Programming the kernel is hard and becoming more so as the system becomes more complex (with more granular locking, etc). The difficulty of running menuconfig is nothing compared to dealing with those issues.
Second, I'm happy with kernel hackers being an elite group. That's totally different than Linux users being an elite group, which I don't feel is true and am glad for. If kernel hackers were not an elite group, I believe code quality would suffer.
And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
There is too much resistence to change in the Linux community. The problem is a simple one: in the minds of Elitists, easier is not better, it's "lamer", "suckier", or "for wussies".
First, as other posters have said, there were valid reasons ESR's system was rejected. They weren't because it was for wussies.
Second, configuring a kernel will never be easy. You have to make a lot of decisions that require technical knowledge. Whether you do that in a text-based interface or a fancy graphical one doesn't matter very much. That doesn't mean a fancy graphical interface shouldn't be made, but it shouldn't be made for the reason of making it easier for mom to use Linux.
The correct solution to make hardware configuration usable for the masses is not to make building a kernel easier but to make building a kernel unnecessary. The system has become more modular over time.[1] Hardware has become friendlier to autodetection. Distributions like RedHat come with a single kernel that will work for just about anyone. When you start up with new hardware, kudzu will recognize it, ask you about it, and load the appropriate driver.
[1] and is still becoming more modular. 2.5 was supposed to completely remove the idea of compiled-in versions of stuff that is modular. I believe this got canned due to time constraints; look for it in 2.7 maybe.
With this system, you teach the AI to practice blacksmithing, let it run day and night for a few days, and come back with a master blacksmith. Just seems like you are taking out the challenge of the game...
That's not challenge, that's drudgery. If you don't want AIs like this to invade your games, play games that require more skill and less repeated action.
Excuse me, but what is the point of inserting a space in URL's that aren't A HREF'd? [...] Is this a part of slashdot's comment system?
Yup, it's part of Slashdot's comment system. The fundamental problem is a bad design decision in the HTML standard - tables expand when the content does not fit in the allocated horizontal space, instead of it being forcibly wrapped. So by inserting a single really long word, you could make the whole page flow really weirdly. Slashdot's "solution" is to make sure there are no really long words. They insert spaces after 20 characters.
I really don't think random mutation with selection is going to be the answer, if there's even an answer to be had. Computers are for automating, humans using them as tools are for innovating.
I think this experiment can work - they just need to vary the experimental conditions a bit more. A few ways come to mind:
Vary the transistors, the lengths of their connections, etc. A previous article said evolutionary things were using surprising properties of the FPGA that would not apply to another FPGA of the same model. When you do this every X generations, ones that depend on those properties will die out. And in this case, varying the length of the connection would modify the properties of the antenna, so the radio one would die out more.
Put it in a Faraday cage. This would kill off the ones that depend on an external signal. (Though it shouldn't always be in a Faraday cage; it should be rebust to interference.)
Alter the temperature. This can affect electrical properties of the silicon as well.
I think the real lesson here is that if you use evolutionary algorithms, you get something that matches the conditions you evolved it under. You need to make those match where you want to use it.
If your view of science is really so crudely utilitarian, I suggest either that you get out of the profession, or (far more likely) you're not really a scientist at all but you've read about it in _Skeptical Inquirer_. Get back to your Linux installation, will you?
I take offense to that statement. Computer science and computer engineering are not suitable places for such a person, either.
Well-designed Leo outlines act both like self-updating tables of contents and self-updating indices. This is in marked contrast to the "stream-of-consciousness" or "narrative" style typically employed in traditional literate programming. [...] At every moment, the overall big picture of a function, class, module, file or project is always at hand.
Very interesting. You've exactly described one big reason I haven't liked literate programming in the past. I always felt it was too hard to the structure of the code and found a folding text editor to be a better guide. The cweb stuff seemed to completely flatten the structure.
For example, when fixing a bug, I clone all nodes related to the bug and gather them in a new part of the outline, called a task node. This task node effectively becomes a view of the project that focuses exclusively on the bug. Any changes I make to code are propagated to all other clones.
These task nodes seem interesting as well. Seems like they would be good ways to find candidates for refactoring. It would be especially useful if you could tie it to a version control system and/or a bug tracking tool. (I.e., "make a task node of what I changed in this commit. Associate it with this bug report.")
Recently, though, I've been using API documentation tools (doxygen, javadoc). Generating output in these formats is really important - it's valuable and expected now for Java/C++ code. I probably wouldn't use leo if it interferes with their processing and can't replace it.
Personally, I was REALLY glad to have 2.96. It was the best, most stable g++ at the time. I'm not saying that people were wrong for hating it, I'm just saying that it suited me.
Why not? I'll say it: people were wrong for hating it. RedHat made the best decision. Their one mistake was not explicitly marking the compiler as their own - people thought it was an official gcc release.
Anyone who thinks the gcc 2.96 compiler is buggy should read this page.
Re:Someone finally makes Linux apps look consisten
on
KDE Gets The Hat
·
· Score: 4, Interesting
Likewise, nobody says `today I wish half my app would look like X, and the other half Y'. The lack onconsistent theming between these two desktops is retarded (If you find that offensive, becausee it implies mentally retarded people are stupid, they are).
Actually, I feel that way.
My ideal situation would be for all applications to look and behave in the same way. It might be themeable, but there's only one theme - all applications use it.
But Qt-based, gtk-based, and XUL-based applications do not behave in the same way. So I would rather they be visually distinct. The consistency of appearance is a foolish one IMHO because it falsely implies a consistency of behavior.
(Obligatory quote: "A foolish consistency is the hobgoblin of small minds." It's not really appropriate - I respect the RedHat developers even if I disagree with this decision. I just like the quote.;)
Fortunately, much of it can be turned off fairly easily, at least in the KDE area. I installed (null) tonight and have done this already. What I don't see any way to get rid of is their bad iconset.
Try any of them. I use Resin. Others are happy with Tomcat. I've never heard of Jetty, but it may be good, too.
The important thing is that you write your application to the servlet spec. If you do that, switching servlet containers will be completely trivial. So if you later decide you've outgrown Tomcat, try something else instead.
For websites you can usually turn it off permanently (if you use IE) but Outlook won't let you do the same for email.
Outlook uses the same certificate store as Internet Explorer. Save your ca.crt file somewhere in your webserver's document root. Serve it out with a application/x-x509-ca-cert MIME type. Internet Explorer will pop up a dialog to allow you to examine and confirm it. Afterward, Outlook will no longer prompt.
So just include "go to this webpage and accept" to your mail setup instructions.
This was the early days of PC networks and client server apps, when the virtuous business departments were wresting control of their data from the evil Data Processors with their fossilized insistence on things like "operational discipline" and "disaster recovery exercises".
If you had ever done a "disaster recovery exercise", you would have known that the backup software was not working. Ironically enough, if you had kept some of their discipline, you would not have had this problem.
You can't open it, discover it's shit (*cough* daikatana *cough* *cough* windows xp), and return it.
Symantec/Norton is good about this. Their license agreements say that authorized resellers must accept returned copies. I returned Norton SystemWorks at Best Buy (don't remember why). I walked up to the customer service desk and they gave me the usual line about not accepting software returns. I showed them the agreement and they had to either accept it or say they weren't an authorized reseller, so they accepted it.
I don't think I've seen that same clause in software agreements from other companies, though.
This is a solved problem. Red Hat, for example, GPG signs the MD5SUM file.
That's a solved problem for RedHat (and other large distributors). You still need a secure channel to get their GPG public key. In RedHat's case, they can ship it on the CD in anticipation of updates. For small people, they need to offer it on their website (same problem) or use our existing (imperfect) PKI system.
That's great, but I'm no coder, hence I am at a loss in terms of creating a web database.
That's cool. I suggest the other, then. You could do a text-based format like LaTeX or DocBook. They aren't as simple as Word, but they should be manageable for a non-programmer. Then you can throw it in a repository (SourceForge/Tigris/Savannah sets it up for you - you just need to use the client) and people can send diffs. They make other formats (plain text, HTML, PDF) for you.
I'd be willing to help a bit setting it up if you decide to do this. (The DocBook tools are a bit of a pain initially, I think.) The email in my profile works.
> I'm well aware that I'm not forwarding the agent to the repository, but I am forwarding the agent from my base machine to where I do my work, and from there I authenticate to the repository.
Right, so the Subversion protocol does not need special support for it.
> Actually, I can easily forsee needs to forward the agent to the repository, if the repository needs to authenticate to something like the filesystem (ala AFS).
Not necessary with mod_dav_svn - it uses standard Unix filesystem operations with its uid no matter how you authenticate to it.
For that matter, Berkeley DB doesn't work on NFS, so it probably doesn't on AFS either. Locking. Same as a RDBMS.
> However, the 'smart server' doesn't need to know anything about the network, just talk over a unix domain socket.
I suppose. But ssh+pipe means that:
it must forks/exec for each connection. I've learned from moving to CGI to Servlets that forking really slows things down. (You'd expect Java stuff to be much slower, but that's not true.) IIRC, sshd forks two processes with privilege seperation. One of those execs your binary (even if it doesn't go through a shell).
You require a Unix UID. I just don't like this idea. It's unnecessary.
It doesn't have the interoperability of HTTP/WebDAV/DeltaV. Those work with a lot of software, and not just in the Unix world. So there's no getting rid of that stuff for me.
> >
Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.
>
If cvs's ever begins to actually be a worry for me, and I consider a different version-control system, I might look into it. But that would likely mean having to work with WebDAV, which is another argument in its own right.
> You assume a basic unix filesystem, not something like AFS, which has rich, powerful (though not sub-file) ACL support.
Right. I assume what's commonly available. And AFS still can't do the right thing. If you've noticed, Subversion goes to the other extreme in terms of numbers of files - everything's in a single Berkeley DB. This allows them to have nice ACID semantics. So granting access in this way would be all-or-none - awful instead of merely bad.
> Furthermore, you really don't need line in/etc/passwd, if that is your concept of a 'shell account'.
That definition is wrong. On www.slamb.org, user slamb has a UID and a login shell, but not a line in/etc/passwd. The NSS method is completely irrelevant.
If you do a "finger cvsonlyuser" on SourceForge, I'm sure it will say "Shell:/cvsonly/shell" or something. When given "-c cvs" arguments, it must invoke cvs. That program is, by definition, a shell. You may be correct that this is not a huge security flaw, but my terminology is right. And also the cvs manual says nothing of how to restrict stuff in this way - again, it should have the best security practices.
> > How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?
> The cryptography for ssh is much more secure than the examples you've give. The authentication means are more powerful, and there is agent-forwarding, both extremely important.
The only example I gave was the access control script - that's authorization. I did not discuss how HTTP authentication & TLS works. Authorization != authentication.
There's nothing wrong with TLS's cryptography. It doesn't do agent forwarding, but it doesn't need to: you aren't forwarding the agent to the Subversion repository. It would be possible to do agent forwarding to the client to get its key. No one's done it (no one's even implemented TLS certificates - that's issue #650, I'm looking forward to it) but it's possible.
> I highly dislike systems writing servers where none is needed (ala CVS with [rs]sh; ssh handles the network).
It's important to have a smart server to have flexible authorization. You simply can't do it otherwise.
This is very similar to any RDBMS. They provide fine-grained security and ACID semantics. They need servers to do it. No one questions them.
But again - if you want it done a different way, do it. Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.
Of course, the dev team has provided you with some nice backup tools, for example, the normal Unix cp command can be used to make hot-backups of your repostories, a very cool trick.
Please check out hot-backup.py. It doesn't do much more than cp, but it doesn't just do cp repository backupdir. It copies the logfiles last. That's important.
> >
CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.
> Noone in their right minds uses this.
Right, no one uses its authentication for anything important. CVS doesn't have a decent protocol. For extra annoyance, they do use it for anonymous stuff, since it is not good to have a Unix account for anonymous people. So you need two different ways of accessing CVS.
> > The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.
> It's a 'kludge' that works extremely well, and fits well into the unix philosophy.
No, it does not work well. There's not a lot of Java code available to talk ssh, for example. It's not good for cross-platform stuff.
Also, ssh handshakes are time-consuming. This is important because cvs reconnects for each operation. In contrast, HTTP has well-defined and well-known standards for keepalive and pipelining.
> > It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.
> False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).
I'm afraid you have me at a disadvantage - I've not seen SourceForge's setup. I'm not a committer on any projects there. However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.
Also, the manual certainly has no better way. If you are able to do so, please patch it. I quote:
It is possible to grant read-only repository access to people using
the password-authenticated server (*note Password authenticated::).
(The other access methods do not have explicit support for read-only
users because those methods all assume login access to the repository
machine anyway, and therefore the user can do whatever local file
permissions allow her to do.)
There are a lot of things not possible to do with Unix file permissions. Saying things can be added but not modified. (You can have setgid directories, but not setuid ones.) One group that can read/write, one that can read, everyone else who can do nothing. Permissions within the files (short of splitting them into more files, which makes Subversion's ACID semantics difficult) . All of these things are possible with Subversion - you just write a Perl script that inspects the transaction and allows or denies it. Please take a look at commit-access-control.pl for an example.
> True. But this has little to do with the transport protocol.
You need a smart server to accomplish this. Subversion's:ext: method of remote access (rerunning the command on the other machine through [rs]sh) doesn't qualify. Arch's modify-via-ftp doesn't either. Those can't ever do anything but the Unix file permisssion way, but with a server between it can decide what is allowed or denied.
You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice. They clearly needed a protocol of some sort. I think using the existing standards was a good choice. Why would something else be better? Why would you not use HTTP? You said:
> CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.
Do you have anything to back that up? How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?
If you're that dead set against that protocol, write a new one. It already has the abstraction - both ra_local and ra_dav are supported. Write a new ra_XXX if you so desire. And a new server to replace mod_dav_svn. Of course, no one will use it - the DAV stuff works well. But maybe you'd feel better.
CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.
CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.
The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access. It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that. Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".
HTTP/WebDAV/DeltaV is nice for a few reasons:
the protocols were already made. HTTP, TLS, WebDAV, and DeltaV all existed beforehand. The authentication and stuff were settled. It saves work designing protocols.
Support of existing software. You can mount a Subversion repository read-only with no special software in most operating systems. ("Web folders" under Win2K for example. Try it. http://svn.collab.net/svn/repos/trunk) Eventually, even write access with automatic versioning. (Which means the log messages will be pretty worthless, but it has some of the advantages of revision control and is completely transparent.) DeltaV-supporting software will probably start to come out pretty soon as well.
Existing code. Apache has a pretty solid server architecture. It divvies up the requests, handles TLS, does authentication, logging, etc. mod_dav was already written as well. mod_dav_svn is a pretty small part of the whole.
Of course, I'd take submissions as comments here or via email. I'd 'publish' the book via the web once I got enough submissions to make the book at least about 40-50 pages in length or 30 recipes (whichever comes last), and as submissions came in I'd update the book.
Better yet: do one of the following:
Put the DocBook (or whatever format) source in revision control so people can see it progress. Accept patches that way (in addition to other ways, if you want).
make a database so people can click and add one. And add their comments to it, etc. Lots of dynamic things you can do here.
It's nice for people to be able to see the work in progress, rather than you releasing a version every so often. It'd make them a lot more likely to keep contributing.
But her interpretations of some her own data [sic] struck me as curious, an interpretation that I picked up in the title of the email she sent me "10.1% of 12-17s are actively downloading/not purchasing music". This implied to me this was a negative stat. Doesn't this also read 90% of teens are both downloading and buying?
No, that statistic says that there are four groups:
Downloading and not buying. 10.1%
Downloading and buying. Unknown. (Only 90% if the next two groups are 0%, which I doubt.)
Not downloading and not buying. Unknown.
Not downloading and buying. Unknown.
But apparently he misquoted, because the original article actually says:
10.1% of 12-17-year-olds who actively download music from the Internet did not purchase a single CD or cassette in the last 12 months.
Which is a completely different statement. And implies that 90% of teens who download music are buying music.
This doesn't really mean that much by itself. There are at least two contrary arguments you could make with it:
90% of teens who download music buy it, as opposed to 30% of teens who don't. So it increases their likelihood to buy. (I just made up that 30% statistic for this example. No idea what the real number is.) It increases their interest in music and therefore their likelihood of buying music.
90% of teens who download music buy it, as opposed to 98% of teens who listen to music but don't download. So it causes artists/labels to lose business. (This has an opposite cause/effect assumption from the argument above.) (Again, the second statistic is fake for this example.)
Clearly to get useful information, you need some way to determine which is cause and which is effect. (Probably a little of both.) And in both cases, I made up a second statistic that wasn't supplied by the article. Real numbers might be interesting.
I'd like to use it to authenticate with HTTP, SSH, IMAP, SMTP, and Jabber - probably others I'm forgetting, too
Also LDAP, PostgreSQL, Oracle
And another question:
Is the authentication to the Identity Provider flexible?
Someone said that the best authentication systems use two of:
something you are (biometrics)
something you have (smart card)
something you know (password)
It would be nice if this system was flexible enough to accomodate that idea, rather than limiting it to a password.
Especially if I have one password for many important systems, I won't want to type it into an untrusted terminal. There are plenty of other choices:
Ideally, I would have a small (smartcard-like) physical device that carries an encrypted private key and has a small keypad. I plug it into the terminal. I enter into my device a PIN number (not the terminal! the terminal should never know the password), it (again, my device, not the terminal) uses the password to decrypt its private key and then sign a mutually agreed-on token. So no replay attacks. Someone would need to grab your smart card and guess your PIN number to compromise your identity. With just a password, anyone who can tamper with the terminal would be able to log in as you whenever they want. Bad enough when it's just one system.
One-time password systems can accomplish the same goal (defeating replay attacks) without requiring a physical device and attachments on terminals. At a cost, of course. If it's stolen, you're screwed. If you run out before you get back to a secure terminal, you can't log in.
etc, etc...there are a million schemes with their advantages and disadvantages. Best to use a system that doesn't limit you to one.
Slashdot Mirror
I think you're not giving the judge enough credit. It's likely that he knows that. He's requiring the companies suing Madster to come up with a way to avoid harming innocent users before he takes any action. If they can't, he might make them demonstrate thoroughly that virtually no one uses the system in a legitimate way. If they can't do either, sucks for them.
They seem to think it's deep but indeed it's just dumb...
Okay, requiring less time, not less skill, seems like a reasonable goal. But also a completely different one than you gave in your first post.
Again, average users don't need to recompile the kernel. Concessions to their lack of technical expertise would be ineffective and unnecessary.
It is almost as important to lower the barrier of entry for kernel hacking, which is very important for Linux's vitality. And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
That wouldn't lower the barrier of entry for kernel hacking. Programming the kernel is hard and becoming more so as the system becomes more complex (with more granular locking, etc). The difficulty of running menuconfig is nothing compared to dealing with those issues.
Second, I'm happy with kernel hackers being an elite group. That's totally different than Linux users being an elite group, which I don't feel is true and am glad for. If kernel hackers were not an elite group, I believe code quality would suffer.
And speaking of that, I haven't been able to get a decent patch since they implemented bitkeeper for the kernel. What's up with that?
Don't know. You'd have to give more specifics...
First, as other posters have said, there were valid reasons ESR's system was rejected. They weren't because it was for wussies.
Second, configuring a kernel will never be easy. You have to make a lot of decisions that require technical knowledge. Whether you do that in a text-based interface or a fancy graphical one doesn't matter very much. That doesn't mean a fancy graphical interface shouldn't be made, but it shouldn't be made for the reason of making it easier for mom to use Linux.
The correct solution to make hardware configuration usable for the masses is not to make building a kernel easier but to make building a kernel unnecessary. The system has become more modular over time.[1] Hardware has become friendlier to autodetection. Distributions like RedHat come with a single kernel that will work for just about anyone. When you start up with new hardware, kudzu will recognize it, ask you about it, and load the appropriate driver.
[1] and is still becoming more modular. 2.5 was supposed to completely remove the idea of compiled-in versions of stuff that is modular. I believe this got canned due to time constraints; look for it in 2.7 maybe.
That's not challenge, that's drudgery. If you don't want AIs like this to invade your games, play games that require more skill and less repeated action.
Yup, it's part of Slashdot's comment system. The fundamental problem is a bad design decision in the HTML standard - tables expand when the content does not fit in the allocated horizontal space, instead of it being forcibly wrapped. So by inserting a single really long word, you could make the whole page flow really weirdly. Slashdot's "solution" is to make sure there are no really long words. They insert spaces after 20 characters.
I think this experiment can work - they just need to vary the experimental conditions a bit more. A few ways come to mind:
I think the real lesson here is that if you use evolutionary algorithms, you get something that matches the conditions you evolved it under. You need to make those match where you want to use it.
I take offense to that statement. Computer science and computer engineering are not suitable places for such a person, either.
Very interesting. You've exactly described one big reason I haven't liked literate programming in the past. I always felt it was too hard to the structure of the code and found a folding text editor to be a better guide. The cweb stuff seemed to completely flatten the structure. For example, when fixing a bug, I clone all nodes related to the bug and gather them in a new part of the outline, called a task node. This task node effectively becomes a view of the project that focuses exclusively on the bug. Any changes I make to code are propagated to all other clones.
These task nodes seem interesting as well. Seems like they would be good ways to find candidates for refactoring. It would be especially useful if you could tie it to a version control system and/or a bug tracking tool. (I.e., "make a task node of what I changed in this commit. Associate it with this bug report.")
Recently, though, I've been using API documentation tools (doxygen, javadoc). Generating output in these formats is really important - it's valuable and expected now for Java/C++ code. I probably wouldn't use leo if it interferes with their processing and can't replace it.
Why not? I'll say it: people were wrong for hating it. RedHat made the best decision. Their one mistake was not explicitly marking the compiler as their own - people thought it was an official gcc release.
Anyone who thinks the gcc 2.96 compiler is buggy should read this page.
Actually, I feel that way.
My ideal situation would be for all applications to look and behave in the same way. It might be themeable, but there's only one theme - all applications use it.
But Qt-based, gtk-based, and XUL-based applications do not behave in the same way. So I would rather they be visually distinct. The consistency of appearance is a foolish one IMHO because it falsely implies a consistency of behavior.
(Obligatory quote: "A foolish consistency is the hobgoblin of small minds." It's not really appropriate - I respect the RedHat developers even if I disagree with this decision. I just like the quote. ;)
Fortunately, much of it can be turned off fairly easily, at least in the KDE area. I installed (null) tonight and have done this already. What I don't see any way to get rid of is their bad iconset.
Try any of them. I use Resin. Others are happy with Tomcat. I've never heard of Jetty, but it may be good, too.
The important thing is that you write your application to the servlet spec. If you do that, switching servlet containers will be completely trivial. So if you later decide you've outgrown Tomcat, try something else instead.
Outlook uses the same certificate store as Internet Explorer. Save your ca.crt file somewhere in your webserver's document root. Serve it out with a application/x-x509-ca-cert MIME type. Internet Explorer will pop up a dialog to allow you to examine and confirm it. Afterward, Outlook will no longer prompt.
So just include "go to this webpage and accept" to your mail setup instructions.
If you had ever done a "disaster recovery exercise", you would have known that the backup software was not working. Ironically enough, if you had kept some of their discipline, you would not have had this problem.
Symantec/Norton is good about this. Their license agreements say that authorized resellers must accept returned copies. I returned Norton SystemWorks at Best Buy (don't remember why). I walked up to the customer service desk and they gave me the usual line about not accepting software returns. I showed them the agreement and they had to either accept it or say they weren't an authorized reseller, so they accepted it.
I don't think I've seen that same clause in software agreements from other companies, though.
That's a solved problem for RedHat (and other large distributors). You still need a secure channel to get their GPG public key. In RedHat's case, they can ship it on the CD in anticipation of updates. For small people, they need to offer it on their website (same problem) or use our existing (imperfect) PKI system.
That's cool. I suggest the other, then. You could do a text-based format like LaTeX or DocBook. They aren't as simple as Word, but they should be manageable for a non-programmer. Then you can throw it in a repository (SourceForge/Tigris/Savannah sets it up for you - you just need to use the client) and people can send diffs. They make other formats (plain text, HTML, PDF) for you.
I'd be willing to help a bit setting it up if you decide to do this. (The DocBook tools are a bit of a pain initially, I think.) The email in my profile works.
Right, so the Subversion protocol does not need special support for it.
> Actually, I can easily forsee needs to forward the agent to the repository, if the repository needs to authenticate to something like the filesystem (ala AFS).
Not necessary with mod_dav_svn - it uses standard Unix filesystem operations with its uid no matter how you authenticate to it.
For that matter, Berkeley DB doesn't work on NFS, so it probably doesn't on AFS either. Locking. Same as a RDBMS.
> However, the 'smart server' doesn't need to know anything about the network, just talk over a unix domain socket.
I suppose. But ssh+pipe means that:
> > Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.
> If cvs's ever begins to actually be a worry for me, and I consider a different version-control system, I might look into it. But that would likely mean having to work with WebDAV, which is another argument in its own right.
Ehh? It would replace WebDAV.
Right. I assume what's commonly available. And AFS still can't do the right thing. If you've noticed, Subversion goes to the other extreme in terms of numbers of files - everything's in a single Berkeley DB. This allows them to have nice ACID semantics. So granting access in this way would be all-or-none - awful instead of merely bad.
> Furthermore, you really don't need line in /etc/passwd, if that is your concept of a 'shell account'.
That definition is wrong. On www.slamb.org, user slamb has a UID and a login shell, but not a line in /etc/passwd. The NSS method is completely irrelevant.
If you do a "finger cvsonlyuser" on SourceForge, I'm sure it will say "Shell: /cvsonly/shell" or something. When given "-c cvs" arguments, it must invoke cvs. That program is, by definition, a shell. You may be correct that this is not a huge security flaw, but my terminology is right. And also the cvs manual says nothing of how to restrict stuff in this way - again, it should have the best security practices.
> > How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?
> The cryptography for ssh is much more secure than the examples you've give. The authentication means are more powerful, and there is agent-forwarding, both extremely important.
The only example I gave was the access control script - that's authorization. I did not discuss how HTTP authentication & TLS works. Authorization != authentication.
There's nothing wrong with TLS's cryptography. It doesn't do agent forwarding, but it doesn't need to: you aren't forwarding the agent to the Subversion repository. It would be possible to do agent forwarding to the client to get its key. No one's done it (no one's even implemented TLS certificates - that's issue #650, I'm looking forward to it) but it's possible.
> I highly dislike systems writing servers where none is needed (ala CVS with [rs]sh; ssh handles the network).
It's important to have a smart server to have flexible authorization. You simply can't do it otherwise.
This is very similar to any RDBMS. They provide fine-grained security and ACID semantics. They need servers to do it. No one questions them.
But again - if you want it done a different way, do it. Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.
Please check out hot-backup.py. It doesn't do much more than cp, but it doesn't just do cp repository backupdir. It copies the logfiles last. That's important.
> Noone in their right minds uses this.
Right, no one uses its authentication for anything important. CVS doesn't have a decent protocol. For extra annoyance, they do use it for anonymous stuff, since it is not good to have a Unix account for anonymous people. So you need two different ways of accessing CVS.
> > The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.
> It's a 'kludge' that works extremely well, and fits well into the unix philosophy.
No, it does not work well. There's not a lot of Java code available to talk ssh, for example. It's not good for cross-platform stuff.
Also, ssh handshakes are time-consuming. This is important because cvs reconnects for each operation. In contrast, HTTP has well-defined and well-known standards for keepalive and pipelining.
> > It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.
> False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).
I'm afraid you have me at a disadvantage - I've not seen SourceForge's setup. I'm not a committer on any projects there. However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.
Also, the manual certainly has no better way. If you are able to do so, please patch it. I quote:
There are a lot of things not possible to do with Unix file permissions. Saying things can be added but not modified. (You can have setgid directories, but not setuid ones.) One group that can read/write, one that can read, everyone else who can do nothing. Permissions within the files (short of splitting them into more files, which makes Subversion's ACID semantics difficult) . All of these things are possible with Subversion - you just write a Perl script that inspects the transaction and allows or denies it. Please take a look at commit-access-control.pl for an example.
> True. But this has little to do with the transport protocol.
You need a smart server to accomplish this. Subversion's :ext: method of remote access (rerunning the command on the other machine through [rs]sh) doesn't qualify. Arch's modify-via-ftp doesn't either. Those can't ever do anything but the Unix file permisssion way, but with a server between it can decide what is allowed or denied.
You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice. They clearly needed a protocol of some sort. I think using the existing standards was a good choice. Why would something else be better? Why would you not use HTTP? You said:
> CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.
Do you have anything to back that up? How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?
If you're that dead set against that protocol, write a new one. It already has the abstraction - both ra_local and ra_dav are supported. Write a new ra_XXX if you so desire. And a new server to replace mod_dav_svn. Of course, no one will use it - the DAV stuff works well. But maybe you'd feel better.
CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.
The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access. It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that. Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".
HTTP/WebDAV/DeltaV is nice for a few reasons:
Better yet: do one of the following:
It's nice for people to be able to see the work in progress, rather than you releasing a version every so often. It'd make them a lot more likely to keep contributing.
From the second article:
No, that statistic says that there are four groups:
But apparently he misquoted, because the original article actually says:
Which is a completely different statement. And implies that 90% of teens who download music are buying music.
This doesn't really mean that much by itself. There are at least two contrary arguments you could make with it:
Clearly to get useful information, you need some way to determine which is cause and which is effect. (Probably a little of both.) And in both cases, I made up a second statistic that wasn't supplied by the article. Real numbers might be interesting.
Also LDAP, PostgreSQL, Oracle
And another question:
Someone said that the best authentication systems use two of:
It would be nice if this system was flexible enough to accomodate that idea, rather than limiting it to a password.
Especially if I have one password for many important systems, I won't want to type it into an untrusted terminal. There are plenty of other choices: