Huh? Linus has always been known for being a bastard, says so himself. You should read LKML some time.
(BTW, Linus works for OSDL now.)
Re:How is this news? GNU Arch 1.1 already does mor
on
Subversion 1.0 Released
·
· Score: 2, Informative
A nice *nix server running an Svn or CVS server can support a medium sized team of developers just fine. How the heck are you supposed to do this using Arch?
I'm really not sure what you're asking. Arch doesn't really need much in the way of hosting, so you could easily have your CVS serving machine host Arch archives as well.
Oh, you mean it really is designed to work primarily, if not only, with Unix-like operating systems?
One of Arch's assumptions is, indeed, a POSIX filesystem; basically every operating supports this, though. Unix-based systems natively, and Windows using Cygwin libraries or compiling with mingw. Actually, Arch users have encouraged the Cygwin team to shake out some bugs in Cygwin's long file handling support, so first-class Win32/Cygwin Arch really isn't that far off. Some of Arch's features (like revision libraries) take advantage of hard links if they're there, so some things may end up taking more disk space on Windows than Unix, but everything works fine.
Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
Yep! Arch's design is primarily as a distributed SCM; there's nothing keeping you from only using the one centralized archive in a centralized development model, though; you just have everyone use one branch. It really can be used just like CVS in that respect if you want to, just the command syntax is slightly different. Hell, I'm developing software in a centralized archive using Arch right now, though I'm the only developer contributing code.
Why do you say Arch is "outright useless for cross-platform" projects? I'm curious to hear what you have to say.
If you're having problems with input devices, search the LKML archives for Vojtech Pavlik's 2.6 input FAQ (he's the maintainer of the kernel's input system). You can find a list of searchable archives at the LKML home/FAQ page.
> Gnome, and the Nautilus file manager (the equivalent of Windows Explorer or Mac OS Finder) allows you to rename files only by right-clickling and choosing "Rename..." from the context-menu.
This is not intuitive at all.
There's no such thing. Nobody will sit down at a computer for the first time and automatically know how everything works, so I don't really buy the argument that putting Rename in a context menu is "less intuitive" than clicking the filename in the right spot. Further, Rename does have a spot in the Edit menu, and is also triggerable by pressing F2:3
I believe the next big thing we'll see GNOME do is tackle hardware integration; e.g., you plug in a USB digital camera and gphoto automatically pops up, not unlike what OS X does with iPhoto. Two big projects in this area that freedesktop.org is pursuing are HAL, a hardware abstraction layer, and D-BUS, an interprocess message sending mechanism that I've heard has lots of influence from KDE's DCOP infrastructure.
Even Mozilla.org has said that Mozilla is really not the preferred browser to use. They suggest Firebird. If you're using GNOME, I'd suggest Galeon. It still has the same plugin installation issues, I'm sure, but in general I find it to be a much better browser.
Slashdotted because ...
on
Review: KDE 3.2
·
· Score: 4, Interesting
Wow. I'm impressed that the entire page actually loaded, instead of just timing out. So the server was able to at least send me a couple bytes every second to keep timing out, that's impressive.
I was kind of shocked to see what they were doing with the screenshots though... those "thumbnails" on the review page? They're not; they're just the pics they link to, resized a bit using img width= height=... I didn't know people were still that stupid, especially given that at least one was full desktop sized.
That having been said, I didn't find the screencaps even particularly flattering; not that I dislike KDE (though I don't use it), but... they were kind of boring. Everything was of empty windows; a little data to make things look, um, real would have been nice:3 It also hit me that KDE seems to have more K-programs than GNOME has G-programs now, which is just ugly.
The "hard to code for" argument was more relevant when RISC was a new idea, over a decade ago. Compiler optimization techniques have evolved a bit since then. (That's most of where compiler development has been focused for the past decade or so, optimization.) And barring that, how many projects have any significant portion of them written in assembly code by humans? And I admit my naivete, but I can't think offhand of an architecture that uses register windows like SPARC does. (Still, it is SPARC, and it is Sun, so... )
I agree, though, that it's amazing how much stock people put in a RISC vs. CISC debate that's largely irrelevant now. As long as we don't see a return to VAX's POLY, I think I'll manage ^_^
Compiler support is pretty much a non-issue with compiler technology where it is today.
More interesting would be for Intel to license HP technology that basically translates object code from one machine to object code for another, in hardware, on the fly. Instant binary compatibility.
See, hearing about things like this pisses me off.
When I think of all the nice system lines that have died off because their parent companies decided "Well, we could just have Intel make our 64-bit chips, and then make money selling systems", and all the technically nice architectures that are basically dead now because of decisions like that (MIPS, Alpha, et. al)... it's kind of depressing.
I mean, I wouldn't mind if Itanium had been more successful. It was actually neat to think of Digital's EV8 team building SMT technology into Itanium. (Is this the work that's been manifested as HT on P4 on Xeon-class machines?) Especially since EPIC is supposed to make things so much different. But... it hasn't taken off. The real pisser, though, is to think that the dominant 64-bit architecture of the future might essentially be i386 with more and bigger registers. Hopefully at least IBM will step in with its POWER-based solutions. Man, if I ever get drunk and start bitter rants, I swear it'll be about processor architectures...
-mm is not in the final release. 2.6.0-test11-mm1 has something like 300 patches in it (IIRC). From activity on LKML, I suspect that the next Big Thing to happen will be working on merging this into 2.6 proper. (There have been a lot of patches from lots of people, sitting and waiting for inclusion for 2.6.1 or later. -mm will probably be sorted through just like those.)
For a summary of changes from 2.4 to 2.6, read Dave Jones' "post-Halloween" document. (The Changelog only lists changes from -test11 to 2.6.0 and so is not very useful. However, a full Changelog from 2.5.0 to 2.6.0 would be massive information overload, as well as just not terribly useful for a broad picture of what's different.)
Read Dave Jones' "post-Halloween documents". You'll have to read them from backups, since the host davej's website is usually on recently suffered some sort of catastrophic hardware failure.
Buggy front page scripts, my guess. After all, the latest stable version was 2.4.xx for a long time, so just give hpa a little bit to make a shiny new "The latest 2.4.x release of the kernel is: " row.
Unix wasn't either designed with security in mind. Of course, neither was Windows. Both have rather nice security features (Windows, for example, can be configured to do C2 auditing out of the box, whereas you need to patch your kernel to do this for GNU/Linux, though I believe Solaris can do it out of the box as well)... however, neither was built from the ground up with security in mind. No modern operating system was. (And no, OpenBSD does not count, being essentially Unix.)
You are correct, however, that Unix was designed to be multiuser while Windows was not.
"Microsoft's FAT file system license offers limited rights to issued and pending Microsoft patents on FAT file system technology, as well as rights to implement the Microsoft FAT file system specification."
It appears that Microsoft is selling a liscense to implement their filesystem. However, the liscense is for manufacturers of consumer electronics and removable media. It's unclear, based on my lack of knowledge of this legal area and the ambiguity of this document, whether (e.g.) writers of software targeting non-consumer electronics products (such as personal computers) would need to approach Microsoft for liscensing.
However, the patents all have to do with VFAT long filenames. Thus, it appears that a manufacturer may only have to refuse to deal with anything other than valid 8.3 filenames to avoid the patent liscensing hassle. I don't know how Microsoft could claim to enforce a restriction on implementing anything on FAT that's not patented; I don't believe they can, under US law, but like I said, I have a very incomplete understanding of US law in this respect.
I have a bone to pick with the summary. -O3 probably won't help your performance in the first place, and will likely degrade it. -O2 or -Os, with maybe a few -mxxxx or -fxxxx flags, would be better. Of course, optimizing your code by making it not do stupid things is the best. (Though compiling with -O2 is pretty much standard and a good thing.)
You wouldn't do this in Bitkeeper if you were a privacy freak. Remember, the Bitkeeper liscense requires that you maintain open logging. Realistically, this means that info about what files you change get transmitted across the network; I don't know if it's encrypted or not. It's not that big of a deal, but I'm sure someone here would care.
That being said, doing it in BK would be a compelling alternative if you wanted to use the same/home repo across (say) three or more machines, since you could take advantage of its more complex merge operators. Arch or SVN also might be good ideas. (Don't have any experience with Subversion, though.)
I wonder why CVS, and not something more advanced, like Arch or Subversion? Especially since he outright complains about common limitations in CVS, like moving files and dealing with directories at all. If he's hoping, as he says, "for a better replacement some day", why not see what the present has to offer?
I mean, that's not to say that alternative systems are perfect, either. I'm going through the process of learning arch now. There's a learning curve, but not nearly as big as it's made out to be. Still, using something else (almost anything else) would probably help on things like the merging issues, especially since he mentions that sometimes it's a pain keeping things in sync between three of his machines.
The mailing list post that is linked to in the headline, if you'd read it, mentions that Linus doesn't want to do anything major before release. I'd consider "bug changes" critical, personally. Linus is only taking bug fixes for major issues. Witness:
"So guys, let's work on this even more for test10. I'm going to _totally_ ignore patches that aren't for major bugs. Don't send me anything that _others_ wouldn't consider horribly critical."
Haven't you read the old Ninja Turtles novelizations (not the original graphic novels, but some cheesy books someone wrote)? As Donatello said, it obviously means "Quite Excellently Done."
*grabs a book and runs giggling from the Latin majors and logic students*
Great, now Linux can be Windows compatible and crash just as much as Windows does!
The most common cause for Windows crashes these days, I'm told, is bad drivers, not Windows itself. Do we really want to use such drivers?
Slashdot Mirror
Huh? Linus has always been known for being a bastard, says so himself. You should read LKML some time.
(BTW, Linus works for OSDL now.)
A nice *nix server running an Svn or CVS server can support a medium sized team of developers just fine. How the heck are you supposed to do this using Arch?
I'm really not sure what you're asking. Arch doesn't really need much in the way of hosting, so you could easily have your CVS serving machine host Arch archives as well.
Oh, you mean it really is designed to work primarily, if not only, with Unix-like operating systems?
One of Arch's assumptions is, indeed, a POSIX filesystem; basically every operating supports this, though. Unix-based systems natively, and Windows using Cygwin libraries or compiling with mingw. Actually, Arch users have encouraged the Cygwin team to shake out some bugs in Cygwin's long file handling support, so first-class Win32/Cygwin Arch really isn't that far off. Some of Arch's features (like revision libraries) take advantage of hard links if they're there, so some things may end up taking more disk space on Windows than Unix, but everything works fine.
Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
Yep! Arch's design is primarily as a distributed SCM; there's nothing keeping you from only using the one centralized archive in a centralized development model, though; you just have everyone use one branch. It really can be used just like CVS in that respect if you want to, just the command syntax is slightly different. Hell, I'm developing software in a centralized archive using Arch right now, though I'm the only developer contributing code.
Why do you say Arch is "outright useless for cross-platform" projects? I'm curious to hear what you have to say.
If you're having problems with input devices, search the LKML archives for Vojtech Pavlik's 2.6 input FAQ (he's the maintainer of the kernel's input system). You can find a list of searchable archives at the LKML home/FAQ page.
Err, I'm feeling generous, here: 2.6 input drivers FAQ ^_^;
You may be confusing the "USB event subsystem" (of which I'm really not sure you're talking about) with the generic input system.
> Gnome, and the Nautilus file manager (the equivalent of Windows Explorer or Mac OS Finder) allows you to rename files only by right-clickling and choosing "Rename..." from the context-menu.
:3
This is not intuitive at all.
There's no such thing. Nobody will sit down at a computer for the first time and automatically know how everything works, so I don't really buy the argument that putting Rename in a context menu is "less intuitive" than clicking the filename in the right spot. Further, Rename does have a spot in the Edit menu, and is also triggerable by pressing F2
I believe the next big thing we'll see GNOME do is tackle hardware integration; e.g., you plug in a USB digital camera and gphoto automatically pops up, not unlike what OS X does with iPhoto. Two big projects in this area that freedesktop.org is pursuing are HAL, a hardware abstraction layer, and D-BUS, an interprocess message sending mechanism that I've heard has lots of influence from KDE's DCOP infrastructure.
Even Mozilla.org has said that Mozilla is really not the preferred browser to use. They suggest Firebird. If you're using GNOME, I'd suggest Galeon. It still has the same plugin installation issues, I'm sure, but in general I find it to be a much better browser.
Wow. I'm impressed that the entire page actually loaded, instead of just timing out. So the server was able to at least send me a couple bytes every second to keep timing out, that's impressive.
... those "thumbnails" on the review page? They're not; they're just the pics they link to, resized a bit using img width= height= ... I didn't know people were still that stupid, especially given that at least one was full desktop sized.
... they were kind of boring. Everything was of empty windows; a little data to make things look, um, real would have been nice :3 It also hit me that KDE seems to have more K-programs than GNOME has G-programs now, which is just ugly.
I was kind of shocked to see what they were doing with the screenshots though
That having been said, I didn't find the screencaps even particularly flattering; not that I dislike KDE (though I don't use it), but
The "hard to code for" argument was more relevant when RISC was a new idea, over a decade ago. Compiler optimization techniques have evolved a bit since then. (That's most of where compiler development has been focused for the past decade or so, optimization.) And barring that, how many projects have any significant portion of them written in assembly code by humans? And I admit my naivete, but I can't think offhand of an architecture that uses register windows like SPARC does. (Still, it is SPARC, and it is Sun, so ... )
I agree, though, that it's amazing how much stock people put in a RISC vs. CISC debate that's largely irrelevant now. As long as we don't see a return to VAX's POLY, I think I'll manage ^_^
Compiler support is pretty much a non-issue with compiler technology where it is today.
More interesting would be for Intel to license HP technology that basically translates object code from one machine to object code for another, in hardware, on the fly. Instant binary compatibility.
See, hearing about things like this pisses me off.
... it's kind of depressing.
... it hasn't taken off. The real pisser, though, is to think that the dominant 64-bit architecture of the future might essentially be i386 with more and bigger registers. Hopefully at least IBM will step in with its POWER-based solutions. Man, if I ever get drunk and start bitter rants, I swear it'll be about processor architectures ...
When I think of all the nice system lines that have died off because their parent companies decided "Well, we could just have Intel make our 64-bit chips, and then make money selling systems", and all the technically nice architectures that are basically dead now because of decisions like that (MIPS, Alpha, et. al)
I mean, I wouldn't mind if Itanium had been more successful. It was actually neat to think of Digital's EV8 team building SMT technology into Itanium. (Is this the work that's been manifested as HT on P4 on Xeon-class machines?) Especially since EPIC is supposed to make things so much different. But
Followed shortly thereafter by "Do not listen to ASIMO. He is inferior."
-mm is not in the final release. 2.6.0-test11-mm1 has something like 300 patches in it (IIRC). From activity on LKML, I suspect that the next Big Thing to happen will be working on merging this into 2.6 proper. (There have been a lot of patches from lots of people, sitting and waiting for inclusion for 2.6.1 or later. -mm will probably be sorted through just like those.)
The Changelog is only the changes from 2.6.0-test11 to 2.6.0, which isn't very illuminating at all.
Read Dave Jones' post halloween document. It summarizes the differences between 2.4 and 2.6.
For a summary of changes from 2.4 to 2.6, read Dave Jones' "post-Halloween" document. (The Changelog only lists changes from -test11 to 2.6.0 and so is not very useful. However, a full Changelog from 2.5.0 to 2.6.0 would be massive information overload, as well as just not terribly useful for a broad picture of what's different.)
Read Dave Jones' "post-Halloween documents". You'll have to read them from backups, since the host davej's website is usually on recently suffered some sort of catastrophic hardware failure.
Buggy front page scripts, my guess. After all, the latest stable version was 2.4.xx for a long time, so just give hpa a little bit to make a shiny new "The latest 2.4.x release of the kernel is: " row.
Unix wasn't either designed with security in mind. Of course, neither was Windows. Both have rather nice security features (Windows, for example, can be configured to do C2 auditing out of the box, whereas you need to patch your kernel to do this for GNU/Linux, though I believe Solaris can do it out of the box as well) ... however, neither was built from the ground up with security in mind. No modern operating system was. (And no, OpenBSD does not count, being essentially Unix.)
You are correct, however, that Unix was designed to be multiuser while Windows was not.
Except, the linked webpage clearly states:
"Microsoft's FAT file system license offers limited rights to issued and pending Microsoft patents on FAT file system technology, as well as rights to implement the Microsoft FAT file system specification."
It appears that Microsoft is selling a liscense to implement their filesystem. However, the liscense is for manufacturers of consumer electronics and removable media. It's unclear, based on my lack of knowledge of this legal area and the ambiguity of this document, whether (e.g.) writers of software targeting non-consumer electronics products (such as personal computers) would need to approach Microsoft for liscensing.
However, the patents all have to do with VFAT long filenames. Thus, it appears that a manufacturer may only have to refuse to deal with anything other than valid 8.3 filenames to avoid the patent liscensing hassle. I don't know how Microsoft could claim to enforce a restriction on implementing anything on FAT that's not patented; I don't believe they can, under US law, but like I said, I have a very incomplete understanding of US law in this respect.
I have a bone to pick with the summary. -O3 probably won't help your performance in the first place, and will likely degrade it. -O2 or -Os, with maybe a few -mxxxx or -fxxxx flags, would be better. Of course, optimizing your code by making it not do stupid things is the best. (Though compiling with -O2 is pretty much standard and a good thing.)
Heh. I have heard that Subversion archives are just awful to get set up right.
How do you mean that "arch is a hack onto CVS"? (I guess I had forgotten about archive format stability, though.)
You wouldn't do this in Bitkeeper if you were a privacy freak. Remember, the Bitkeeper liscense requires that you maintain open logging. Realistically, this means that info about what files you change get transmitted across the network; I don't know if it's encrypted or not. It's not that big of a deal, but I'm sure someone here would care.
/home repo across (say) three or more machines, since you could take advantage of its more complex merge operators. Arch or SVN also might be good ideas. (Don't have any experience with Subversion, though.)
That being said, doing it in BK would be a compelling alternative if you wanted to use the same
I wonder why CVS, and not something more advanced, like Arch or Subversion? Especially since he outright complains about common limitations in CVS, like moving files and dealing with directories at all. If he's hoping, as he says, "for a better replacement some day", why not see what the present has to offer?
I mean, that's not to say that alternative systems are perfect, either. I'm going through the process of learning arch now. There's a learning curve, but not nearly as big as it's made out to be. Still, using something else (almost anything else) would probably help on things like the merging issues, especially since he mentions that sometimes it's a pain keeping things in sync between three of his machines.
The mailing list post that is linked to in the headline, if you'd read it, mentions that Linus doesn't want to do anything major before release. I'd consider "bug changes" critical, personally. Linus is only taking bug fixes for major issues. Witness:
"So guys, let's work on this even more for test10. I'm going to _totally_ ignore patches that aren't for major bugs. Don't send me anything that _others_ wouldn't consider horribly critical."
It means, Quite Easily Done, or Q.E.D.
Oh, please ...
Haven't you read the old Ninja Turtles novelizations (not the original graphic novels, but some cheesy books someone wrote)? As Donatello said, it obviously means "Quite Excellently Done."
*grabs a book and runs giggling from the Latin majors and logic students*
Great, now Linux can be Windows compatible and crash just as much as Windows does! The most common cause for Windows crashes these days, I'm told, is bad drivers, not Windows itself. Do we really want to use such drivers?