Wouldn't a new system possibly ask/know where to look for your key, and (like ssh) ask for a password for the private key if there is one? That'd made sense. Just like OpenSSH's public key login, only you do it locally. The difference is that you have to make sure the key itself isn't local, or is at least chmodded safely.
Is it practical to have pubkey authentication not only for SSH, but also for local and indeed any login? This is very untraditional but could certainly fend off the problems people usually have with password authentication. There's a loss of convenience I suppose, but then having no password at all is optimally convenient anyway - and we don't stoop that low.
Wow. Okay, going to make sure I never use PAM even accidentally. Shame many Linux systems seem to basically rely on it; but then I don't rely on Linux systems.
Precisely. People give C a bad rap for not doing enough for the programmer, so mistakes are easy to make. While it isn't 'wrong', it's usually the ones who can't stand to think in a logical and careful way. If you know what you're doing and how the compiler/processor is going to take things, C is possibly the greatest language out there. A few years of experience mentally tracing code makes BOs just not happen.
As for PAM not being used, why? Personally I hate PAM for very little reason, but I'd like to have some reasons for reference:)
What about that you need ezm3 to compile it, which is a HUGE download and compile time in itself? I'd be very happy to have a C replacement for CVSup even if it meant writing it myself.
Definitely, I found FreeBSD 5.3 to be very responsive (with SCHED_ULE but without the PREEMPTION option, as these two don't seem to rub together well), but it had way too many flake-outs to keep me trusting. Performance aside, things like randomly starting to drop packets on a perfectly fine Realtek 8139 network card until I ifconfig it again (no other system had this problem) really nailed the coffin. In spite of these things it's still a highly usable and functional system, but it doesn't offer enough advantages over other systems (especially DragonFly BSD) to stay a favorite.
This doesn't matter much to Net/OpenBSD (much less the topic itself) but is worth mentioning. If NetBSD had: 1) Support by commercial driver vendors like NVidia 2) A larger range of software in pkgsrc 3) Greater responsiveness under load, it would be a very ideal desktop system, the rest supported by its own amazing attention to code quality and correctness, which result in a system that you can stake your life on in terms of stability and security (and performance is rather amazing in 2.0 too, gives Linux some things to think about).
Do you write any code? Typically the 'right' solution is fast. What we see in gcc 3.x is not only a colossal regression in performance, but also in quality and efficiency, in both the software itself and the binaries it generates. Performance IS a factor of correctness in code, even if not in the Merriam-Webster definition, which I very much doubt factored in programming ideals.
I don't mean to argue or insult, far from; I'm just saying that, from a software correctness point of view, performance is important. Stability and security are more important, but if performance CAN come without impacting these two (and this is how it was in gcc 2.95), it has to in order for the code to be 'correct'. Debatable, maybe, but that's going to stay the popular view.
CVS provides a way for BSDs to fetch source without resorting to ports. This is a very good reason to keep it in. Personally I hated having to install cvsup in FreeBSD just to keep sources up to date (if it's possible by CVS itself, it isn't very well documented what servers are useful; when I tried I ended up with half a source tree from a year ago or something), and despite the 'inefficiency' of pure CVS, having it in the base system is a great convenience - and now that I use NetBSD, I can fetch the whole source tree of that and it WILL be the latest.
While this doesn't directly relate to the Subversion/etc debate, it's just my view on why at least a functional CVS client should be in the base system. In the same way the public CVS servers should be kept properly up-to-date and not left behind in favor of CVSup.
Here's where I step in with a favorite URL - http://kerneltrap.org/node/view/4126 - wherein Linus himself points out that GCC 3.x is a generally worse C compiler, with some advantages in C++ compiling being its only real saving throws.
While I can't honestly say BSD projects haven't come under the same kind of problems (FreeBSD 5, for instance, which at least right now isn't a pretty sight), the tendancy is not to replace perfectly fine systems (like gcc 2.95's essential core, which was fast and light) with monstrosities (gcc 3.x). If something new is to be implemented, it has to be Right in design and in practice. If a BSD project wrote a compiler, it would be free, light, very UNIXy (functional, not kitschy), and few people would care because it's not GPL and anything non-GPL must be inferior, right? Some people...
You're probably the kind of person who said that replacing the UNIX cc was a waste of time, too. There are reasons besides a niche being filled, you know. Code quality, license freedom, making changes when the original developers won't, etc.
There should be a 'Narrow-minded Idiot' moderation on Slashdot.
Do people really use CVS as a backend for IMAGES and VIDEO? From everything I know of CVS, it is designed entirely for plaintext (notice how many projects uuencode anything they want to store in CVS?), since generating 'diffs' for binary files is impractical, especially compression where changes tend to have cascading effects.
If it's just for keeping a history, that's another story, but then CVS is overkill. I could write an authenticating file server with history and everything in a weekend (second day is testing/refinement of course) in C, no problems. CVS does a lot more than that, and crippling it down to a file server - worse still for files it should NOT be handling - is silly by anyone's standards. I pity whatever big company is doing this.
There's a small thing holding back Net and OpenBSD (I'm an advocate of both, this isn't trolling, just an observation) which is lack of real kernel preemption in favor of clean, simple code. While you do get the most out of your cycles this way (and it shows on lower spec machines), even on higher end machines even moderate load (in my experience, any compile job, even -j1) can make the user interface very unresponsive.
My worst experience (possibly made worse by flaky hardware) of this is NetBSD 2 a couple of days ago, doing a pkg_chk -u round that made my entire day consist of 10-second lag after typing things before they appeared, and almost having to resort to elinks because Firefox couldn't do anything useful. On a DESKTOP system, traditionally an interactive system, this is a Very Bad Thing, since it reduces productivity if the system is under any other load.
The irony is that the Net/OpenBSD approach results in typically better server/overall performance, where 'responsiveness' isn't an issue, and hence they really do make great servers. The way people say "Net and OpenBSD are still for servers" has its truth, but you won't stop me using (at least) NetBSD on a desktop instead of Linux just for the peace of mind.
If there's a clean and simple way to improve responsiveness without significantly hurting performance, it should be implemented. Apparently a new thread scheduler would be enough, but even that is quite a task.
It's slower than gcc 3? Damn. Does anyone else here remember how fast gcc 2.95 was? You'd think a new, fresh project based on 'correctness' would at least keep up with 2.95, and run circles around 3.
I was excited by the project for the 30 seconds between learning it existed and learning it's actually no better than gcc.
I'll still be using the GPL for most of the code I write, because I want as many people as possible to use it
Well you can count out anyone who wants to use it in a closed-source product or environment where stapling the very large GPL to everything isn't practical. GPL just ensures derived code will STAY open forever, it doesn't mean more people will get to use it - less, in fact, unless they flock to it based on license.
There's more to it than that, though. BSDs run on a "least surprise" tactic, whereby major systems shouldn't change unless there is something REALLY wrong. The BSDs have all used CVS right from the early versions, and can still be fetched this way. If any of them were to drop CVS support for Subversion, for instance, users would have to adapt, and with the significant user base of BSD, that's quite a disruption.
An honest question: Can Subversion import a CVS history and all branches and everything else relevant without any need for hand-hacking? Because when you want to migrate decades of source to a new system and keep it in working order, you don't want to have to mangle every file by hand. If Subversion does this then it's not entirely impractical to implement it - but since the biggest TRIVIAL (can be fixed without disrupting user base's expectations) problems in CVS can be fixed with a compatible re-write, it makes sense to do it that way. In this regard I congratulate OpenBSD on yet another brilliant and far overdue idea.
Well the BSD license still is the 'freest' of the popular open source licenses, in that it only prevents people removing the copyright notice and basic clauses. Besides that, code can be integrated into any project, commercial or otherwise.
Many GNU evangelists think that this means BSDs "help" commercial software and hence are sabotaging OSS ideaology, but in reality commercial software will always be around, and if it's based on secure, trusted and matured code bases rather than hack-jobs they have to write from scratch, chances are commercial software will be good. From a security standpoint, less compromised machines out there mean less pollution and less chance of distributed DoS/brute force against any system.
OpenBSD in this regard is a very heavy contributor, providing a breeding ground for quality software that others see fit to use. Since it's all BSD, anyone can use it how they want. Think where we'd be today without OpenSSH, for instance.
Actually that was originally said about FreeBSD before, and just hacked to say NetBSD instead. If you're going to troll, at least give readers some credit.
If I had my way Slashdot wouldn't allow anonymous posting to begin with.
Number of dirty buffers left. Notice how they count down, and at 0, it's done?
It's more obvious in FreeBSD 5 which has a completely broken sync system, where dirty buffers sometimes go UP, and can take 30 seconds to sync it all... and wait for 3 consecutive 0s before completing. I remember when that change was first brought in and thinking "okay, time to move to NetBSD".
Exactly. As they say, when you have the same code run with the right glue on countless different hardware (especially CPU) configurations, you tend to notice problems much quicker. If something is bloated you might not even notice on a fast x86, but run it on a vax and it comes up. Security works the same way, and that's why OpenBSD ports, to see if anything comes up.
Some systems run on many archs but don't take advantage of it properly, by having redundant code and not abstracting properly. Defeats a big advantage of portability, really.
NetBSD's bragging rights like supporting "USB on Apple Power Macintosh machines before Apple had MacOS X even booting" are just evidence of this. They had USB support on x86 just fine - all it took was supporting the basic differences of the Mac system and the machine-independent drivers just worked. And if there were any problems, they would have been fixed, potentially benefiting all implementations.
The one curious issue of NetBSD's otherwise amazing hardware support is the breakage of the Tulip LAN driver. No clue about that.
It isn't enough for grandparent that Linus himself says the new gccs are slower than the oldies? (http://kerneltrap.org/node/view/4126) Okay, you can try it yourself (install, however you do, gcc 2.95.x and 3.3 or 3.4 or whichever you think is the better one, and compile the same code).
The new GCCs support more targets with more optimization and this is of course helpful, and C++ support is actually good for something now. But this should not have come with such a heavy performance cost. Care to argue this point? I'm more than willing (well not really) but you'd be wasting your time.
As for thinking I'm a lame troll, fair enough, join the club. Lots of people think that about me. What I say, I say from experience or research. If you don't like it, disprove it, don't just whinge. If you can't disprove it, deal with it. This applies to everyone.
Not mentioned above is that you can set PKG_PATH to fetch the packages from a 1.6.2 (or whatever) directory on the FTP server(s). This is what you should do possibly in csh.login or whatever you use, but note that you have to unset PKG_PATH before doing pkgsrc work (it will warn you about this).
Any reason not to upgrade to 2.0, though? It's managed not to be bloated which is a huge plus. The only downside is that the new gcc is very slow (that's GNU for you) compared to 2.95, but can generate faster code sometimes. You can build and install a netbsd-2-0 CVS tree on a 1.6 system (build.sh) and install it right over. But remember - kernel (with COMPAT_16) first, reboot, THEN world!
Re:NetBSD is faster and more scalable then OpenBSD
on
NetBSD 2.0 RC5 Tagged
·
· Score: 1
That wasn't a flame, just wondering how anyone could ask at this point in time what scalability benches are being discussed. Don't take it so harshly.
The architecture numbers were a tangent mention that just happened to appear in a post otherwise replying to you. These things happen.
Take it easy, it's not worth popping a vein on Slashdot.
You can see links on Slashdot (and hence slashdot them) without singup, though. Either Slash should be made 'subscription only' and require, yes, dedication to registration... or throttle the number of users that can see links LOCALLY, and hope they don't share with their friends.
Honestly though, it's more a case of "if they can't handle the load, they shouldn't be mentioned on slash in the first place".
Native threading is one very big thing (surprisingly big thing even), but generally they seem to have optimized everything and it all adds up to blinding performance, especially in how well it uses hardware. You won't see any hardware NOT doing the best it possibly can, is what I mean to say. And the hardware support itself is what I would call "clean like Linux, but with sensible messages". Hotplugging and everything is kernel-level unlike FreeBSD, which I rather like.
More interesting changes will come in AFTER 2.0 is released, since some new stuff is happening in -current that has to wait until after release. On this topic, the 2.0 release HAS BEEN TAGGED, so it's a matter of days before the release is official! The wait is over!
The power to serve - on the platform of your choice.
Slashdot Mirror
Wouldn't a new system possibly ask/know where to look for your key, and (like ssh) ask for a password for the private key if there is one? That'd made sense. Just like OpenSSH's public key login, only you do it locally. The difference is that you have to make sure the key itself isn't local, or is at least chmodded safely.
Is it practical to have pubkey authentication not only for SSH, but also for local and indeed any login? This is very untraditional but could certainly fend off the problems people usually have with password authentication. There's a loss of convenience I suppose, but then having no password at all is optimally convenient anyway - and we don't stoop that low.
Wow. Okay, going to make sure I never use PAM even accidentally. Shame many Linux systems seem to basically rely on it; but then I don't rely on Linux systems.
Precisely. People give C a bad rap for not doing enough for the programmer, so mistakes are easy to make. While it isn't 'wrong', it's usually the ones who can't stand to think in a logical and careful way. If you know what you're doing and how the compiler/processor is going to take things, C is possibly the greatest language out there. A few years of experience mentally tracing code makes BOs just not happen.
:)
As for PAM not being used, why? Personally I hate PAM for very little reason, but I'd like to have some reasons for reference
What about that you need ezm3 to compile it, which is a HUGE download and compile time in itself? I'd be very happy to have a C replacement for CVSup even if it meant writing it myself.
Definitely, I found FreeBSD 5.3 to be very responsive (with SCHED_ULE but without the PREEMPTION option, as these two don't seem to rub together well), but it had way too many flake-outs to keep me trusting. Performance aside, things like randomly starting to drop packets on a perfectly fine Realtek 8139 network card until I ifconfig it again (no other system had this problem) really nailed the coffin. In spite of these things it's still a highly usable and functional system, but it doesn't offer enough advantages over other systems (especially DragonFly BSD) to stay a favorite.
This doesn't matter much to Net/OpenBSD (much less the topic itself) but is worth mentioning. If NetBSD had: 1) Support by commercial driver vendors like NVidia 2) A larger range of software in pkgsrc 3) Greater responsiveness under load, it would be a very ideal desktop system, the rest supported by its own amazing attention to code quality and correctness, which result in a system that you can stake your life on in terms of stability and security (and performance is rather amazing in 2.0 too, gives Linux some things to think about).
Do you write any code? Typically the 'right' solution is fast. What we see in gcc 3.x is not only a colossal regression in performance, but also in quality and efficiency, in both the software itself and the binaries it generates. Performance IS a factor of correctness in code, even if not in the Merriam-Webster definition, which I very much doubt factored in programming ideals.
I don't mean to argue or insult, far from; I'm just saying that, from a software correctness point of view, performance is important. Stability and security are more important, but if performance CAN come without impacting these two (and this is how it was in gcc 2.95), it has to in order for the code to be 'correct'. Debatable, maybe, but that's going to stay the popular view.
CVS provides a way for BSDs to fetch source without resorting to ports. This is a very good reason to keep it in. Personally I hated having to install cvsup in FreeBSD just to keep sources up to date (if it's possible by CVS itself, it isn't very well documented what servers are useful; when I tried I ended up with half a source tree from a year ago or something), and despite the 'inefficiency' of pure CVS, having it in the base system is a great convenience - and now that I use NetBSD, I can fetch the whole source tree of that and it WILL be the latest.
While this doesn't directly relate to the Subversion/etc debate, it's just my view on why at least a functional CVS client should be in the base system. In the same way the public CVS servers should be kept properly up-to-date and not left behind in favor of CVSup.
Here's where I step in with a favorite URL - http://kerneltrap.org/node/view/4126 - wherein Linus himself points out that GCC 3.x is a generally worse C compiler, with some advantages in C++ compiling being its only real saving throws.
While I can't honestly say BSD projects haven't come under the same kind of problems (FreeBSD 5, for instance, which at least right now isn't a pretty sight), the tendancy is not to replace perfectly fine systems (like gcc 2.95's essential core, which was fast and light) with monstrosities (gcc 3.x). If something new is to be implemented, it has to be Right in design and in practice. If a BSD project wrote a compiler, it would be free, light, very UNIXy (functional, not kitschy), and few people would care because it's not GPL and anything non-GPL must be inferior, right? Some people...
You're probably the kind of person who said that replacing the UNIX cc was a waste of time, too. There are reasons besides a niche being filled, you know. Code quality, license freedom, making changes when the original developers won't, etc.
There should be a 'Narrow-minded Idiot' moderation on Slashdot.
Do people really use CVS as a backend for IMAGES and VIDEO? From everything I know of CVS, it is designed entirely for plaintext (notice how many projects uuencode anything they want to store in CVS?), since generating 'diffs' for binary files is impractical, especially compression where changes tend to have cascading effects.
If it's just for keeping a history, that's another story, but then CVS is overkill. I could write an authenticating file server with history and everything in a weekend (second day is testing/refinement of course) in C, no problems. CVS does a lot more than that, and crippling it down to a file server - worse still for files it should NOT be handling - is silly by anyone's standards. I pity whatever big company is doing this.
There's a small thing holding back Net and OpenBSD (I'm an advocate of both, this isn't trolling, just an observation) which is lack of real kernel preemption in favor of clean, simple code. While you do get the most out of your cycles this way (and it shows on lower spec machines), even on higher end machines even moderate load (in my experience, any compile job, even -j1) can make the user interface very unresponsive.
My worst experience (possibly made worse by flaky hardware) of this is NetBSD 2 a couple of days ago, doing a pkg_chk -u round that made my entire day consist of 10-second lag after typing things before they appeared, and almost having to resort to elinks because Firefox couldn't do anything useful. On a DESKTOP system, traditionally an interactive system, this is a Very Bad Thing, since it reduces productivity if the system is under any other load.
The irony is that the Net/OpenBSD approach results in typically better server/overall performance, where 'responsiveness' isn't an issue, and hence they really do make great servers. The way people say "Net and OpenBSD are still for servers" has its truth, but you won't stop me using (at least) NetBSD on a desktop instead of Linux just for the peace of mind.
If there's a clean and simple way to improve responsiveness without significantly hurting performance, it should be implemented. Apparently a new thread scheduler would be enough, but even that is quite a task.
It's slower than gcc 3? Damn. Does anyone else here remember how fast gcc 2.95 was? You'd think a new, fresh project based on 'correctness' would at least keep up with 2.95, and run circles around 3.
I was excited by the project for the 30 seconds between learning it existed and learning it's actually no better than gcc.
There's more to it than that, though. BSDs run on a "least surprise" tactic, whereby major systems shouldn't change unless there is something REALLY wrong. The BSDs have all used CVS right from the early versions, and can still be fetched this way. If any of them were to drop CVS support for Subversion, for instance, users would have to adapt, and with the significant user base of BSD, that's quite a disruption.
An honest question: Can Subversion import a CVS history and all branches and everything else relevant without any need for hand-hacking? Because when you want to migrate decades of source to a new system and keep it in working order, you don't want to have to mangle every file by hand. If Subversion does this then it's not entirely impractical to implement it - but since the biggest TRIVIAL (can be fixed without disrupting user base's expectations) problems in CVS can be fixed with a compatible re-write, it makes sense to do it that way. In this regard I congratulate OpenBSD on yet another brilliant and far overdue idea.
Well the BSD license still is the 'freest' of the popular open source licenses, in that it only prevents people removing the copyright notice and basic clauses. Besides that, code can be integrated into any project, commercial or otherwise.
Many GNU evangelists think that this means BSDs "help" commercial software and hence are sabotaging OSS ideaology, but in reality commercial software will always be around, and if it's based on secure, trusted and matured code bases rather than hack-jobs they have to write from scratch, chances are commercial software will be good. From a security standpoint, less compromised machines out there mean less pollution and less chance of distributed DoS/brute force against any system.
OpenBSD in this regard is a very heavy contributor, providing a breeding ground for quality software that others see fit to use. Since it's all BSD, anyone can use it how they want. Think where we'd be today without OpenSSH, for instance.
Actually that was originally said about FreeBSD before, and just hacked to say NetBSD instead. If you're going to troll, at least give readers some credit.
If I had my way Slashdot wouldn't allow anonymous posting to begin with.
Number of dirty buffers left. Notice how they count down, and at 0, it's done?
It's more obvious in FreeBSD 5 which has a completely broken sync system, where dirty buffers sometimes go UP, and can take 30 seconds to sync it all... and wait for 3 consecutive 0s before completing. I remember when that change was first brought in and thinking "okay, time to move to NetBSD".
There are many more images than that, many of which include real women :)
But that's also good, worth keeping. Writing to my memory...
syncing brain... 42 7 done
Exactly. As they say, when you have the same code run with the right glue on countless different hardware (especially CPU) configurations, you tend to notice problems much quicker. If something is bloated you might not even notice on a fast x86, but run it on a vax and it comes up. Security works the same way, and that's why OpenBSD ports, to see if anything comes up.
Some systems run on many archs but don't take advantage of it properly, by having redundant code and not abstracting properly. Defeats a big advantage of portability, really.
NetBSD's bragging rights like supporting "USB on Apple Power Macintosh machines before Apple had MacOS X even booting" are just evidence of this. They had USB support on x86 just fine - all it took was supporting the basic differences of the Mac system and the machine-independent drivers just worked. And if there were any problems, they would have been fixed, potentially benefiting all implementations.
The one curious issue of NetBSD's otherwise amazing hardware support is the breakage of the Tulip LAN driver. No clue about that.
ulib: Right on, and thanks for that.
It isn't enough for grandparent that Linus himself says the new gccs are slower than the oldies? (http://kerneltrap.org/node/view/4126) Okay, you can try it yourself (install, however you do, gcc 2.95.x and 3.3 or 3.4 or whichever you think is the better one, and compile the same code).
The new GCCs support more targets with more optimization and this is of course helpful, and C++ support is actually good for something now. But this should not have come with such a heavy performance cost. Care to argue this point? I'm more than willing (well not really) but you'd be wasting your time.
As for thinking I'm a lame troll, fair enough, join the club. Lots of people think that about me. What I say, I say from experience or research. If you don't like it, disprove it, don't just whinge. If you can't disprove it, deal with it. This applies to everyone.
Not mentioned above is that you can set PKG_PATH to fetch the packages from a 1.6.2 (or whatever) directory on the FTP server(s). This is what you should do possibly in csh.login or whatever you use, but note that you have to unset PKG_PATH before doing pkgsrc work (it will warn you about this).
Any reason not to upgrade to 2.0, though? It's managed not to be bloated which is a huge plus. The only downside is that the new gcc is very slow (that's GNU for you) compared to 2.95, but can generate faster code sometimes. You can build and install a netbsd-2-0 CVS tree on a 1.6 system (build.sh) and install it right over. But remember - kernel (with COMPAT_16) first, reboot, THEN world!
That wasn't a flame, just wondering how anyone could ask at this point in time what scalability benches are being discussed. Don't take it so harshly.
The architecture numbers were a tangent mention that just happened to appear in a post otherwise replying to you. These things happen.
Take it easy, it's not worth popping a vein on Slashdot.
You can see links on Slashdot (and hence slashdot them) without singup, though. Either Slash should be made 'subscription only' and require, yes, dedication to registration... or throttle the number of users that can see links LOCALLY, and hope they don't share with their friends.
Honestly though, it's more a case of "if they can't handle the load, they shouldn't be mentioned on slash in the first place".
Native threading is one very big thing (surprisingly big thing even), but generally they seem to have optimized everything and it all adds up to blinding performance, especially in how well it uses hardware. You won't see any hardware NOT doing the best it possibly can, is what I mean to say. And the hardware support itself is what I would call "clean like Linux, but with sensible messages". Hotplugging and everything is kernel-level unlike FreeBSD, which I rather like.
More interesting changes will come in AFTER 2.0 is released, since some new stuff is happening in -current that has to wait until after release. On this topic, the 2.0 release HAS BEEN TAGGED, so it's a matter of days before the release is official! The wait is over!
The power to serve - on the platform of your choice.