Re:What are NetBSD's strengths?
on
NetBSD 2.0 Released
·
· Score: 5, Interesting
"It's just as secure as OpenBSD, not more."
No, it's not.
-a great deal less of the privsep stuff -no propolice -no W^X
A number of vulnerabilities common to NetBSD and OpenBSD were mitigated by ProPolice on OpenBSD. That was 1.6... but I didn't see anything about propolice on the 2.0 release page.
"I can't think of anything more secure then OpenBSD at the moment though."
There are special cases where other OSes can be more secure, IMO. For example, on a big system where you have to let people in with permissions to do something interesting, rather than a firewall or a server spewing pages, the FreeBSD jail facility can make it more secure in practical terms.
There's usually a better OpenBSD way to do it, but that way is sometimes enough of a PITA that it doesn'thappen. For example, you can give someone root in a FreeBSD jail and just let them do their thing rather than screwing around with systrace on an OpenBSD machine. Jails are a very blunt tool, but they're very effective.
Apart from localized advantages such as that, OpenBSD is the most secure. I just didn't want anyone to think I was a zealot blind to the advantages of other OSes.:)
Re:What are NetBSD's strengths?
on
NetBSD 2.0 Released
·
· Score: 0, Redundant
"Rather, it's just as secure as OpenBSD"
No, it's not.
-a great deal less of the privsep stuff -no propolice -no W^X
A number of vulnerabilities common to NetBSD and OpenBSD were mitigated by ProPolice on OpenBSD. That was 1.6... but I didn't see anything about propolice on the 2.0 release page.
Gator says "free", Firefox says "free". To someone without access to additional information, there's nothing to tell them apart. To people that are savvy enough to not just install ramdom crap, it probably holds back adoption.
"Why doesn't sun want the code from solaris transfered to linux?"
Linux is the competition.
"That's a serious question because it seems to me if you don't want linux (or freebsd) to benefit from solaris code why did you open source it in the first place. The answer is probably something like "because we want people to code for solaris without getting paid"."
Linux kernel code is virtually never used outside of the Linux kernel. *BSD can't use it, for example, and interviews with developers have indicated that even if they could use it, it would be too much of a PITA to port. I don't see how this is different.
Wow. A heart-felt statement from someone that's not even remotely informed.
Section 2.2: "Conditioned upon Your compliance with Section 3.1 below and subject to third party intellectual property claims, each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license"
Wow. Instead of stopping you from distributing it, they actually explicitly say you can.
"Well, maybe they don't know the reasons, maybe they do."
meh. Depends on the manager I guess.
I've been asked to do stuff in Java that was basically the definition of an ideal candidate for Python. Occasionally the Python advantage is so substantial that I'm able to present a completed project almost immediately (eg within a day) that would have taken weeks in Java, but otherwise they don't listen.
Management wants one language that's good at everything, a standard tool so they don't have to look at particulars. That's damaging a lot of the time.
I'm mostly making fun of the concept that any two languages can satisfy a programmer that wants to be able to do a wide range of things, I'm not actually advocating C# or Java, I just picked them because they're the languages that Management likes to use without actually having an idea of the merits of other languages.
"BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter."
C is necessary for enough things that it won't be replaced in our lifetimes. Its use has diminished now that it's not being forced into service for things it was never great at, but it will never be driven out of some areas.
Also, I think it's critical that programmers learn C if only to understand what's going on underneath the newer languages.
Linus is not some kind of deity. He (by his own account) does nothing between kernelspace and small scripts.
I'm very proficient with C, Python and Bash, and I can tell you for a fact: Bash and Python barely compete against each other.
Bash has nothing in the way of nice datatypes. Bash is very slow while Python can be nearly as fast as C (I've gotten it up to 80% when relying heavily on C libraries like regex). Bash can't do more than the most trivial things without helper programs, which while useful, takes forever because it has to keep spawning processes.
For a high level language, Bash has pathetic memory management. Pretty much the only way to get some things done is tempfiles, which is worse than malloc because they're not removed if you don't clean them up.
If you can't hold more than two languages in your head, go home and learn Java and C#. You're only going to get made fun of on slashdot.
Well, because they use an FPGA the card can potentially be reprogrammed to support just enough of OpenGL to do what Quartz Extreme does.
When you think about it, Quartz Extreme only needs to handle a relatively small number of parallel polygons at basically a constant distance away. That's a much simpler job than millions of triangles at arbitrary angles to each other at varying distances and whatnot.
The job the video card does can potentially be as simple as figuring out which window is exposed in a given area and grabbing pixels from the appropriate frame buffer. OpenGL is a good deal more complicated than that, but since both the driver and the FPGA are under our control, I would think it would be possible.
"the Tritium production comes from putting lithium targets in the reactor for an (n,T) reaction. You will get some tritium from deuterium absorbing neutrons, but that is a real PITA to extract."
Huh?
As you and I both said, a D+T fusion reactor can breed its own Tritium from Lithium and neutrons. However, until the reactor is producing its own Tritium, we need some from elsewhere. It is therefore fortunate that we have fission reactors that produce the stuff anyway.
The current batch of robot probes aren't causing any problems for anyone. The worst thing they leave behind is heat sheilds and parachutes, and the parachutes will be broken down in a few decades by UV radiation from the sun (no free oxygen -> no ozone).
The idea is to build a GIANT tower, use solar energy to heat air at the bottom, and then use wind turbines to capture energy from the air as it rises up the tower.
You can put a heat bank at the bottom (probably a lot of water) that releases heat at night. Because it extracts energy from the heat gradient, it still runs fine at night when it's cooler. Also, maintenance on the turbines is easier because they run at one speed in one direction for 50 years.
They've built several prototypes, and results have been good. However, results get better as the tower gets taller, because the air at higher altitude is cooler. This is why the tower has to be so fucking massive.
"Is Helium-3 that much easier to fuse and create energy?"
No. It's harder. It requires higher temperatures, and better containment. The only advantage when used for terrestrial uses would be the lower neutron production as compared to reactions like Deuterium-Tritium (D+He3 still produces neutrons from unwanted D+D reactions).
Deuterium-Tritium produces neutrons, but the only radioactive stuff left behind is the reactor itself, and the isotopes in question have shortish half lives (tens of years for the most part). D+T is the only way to go for the forseeable future:
-First, we know we can build a D+T reactor. We know this because we already have. It doesn't produce useful electricity, and requires more work to be economical, but it's the only reaction to acheive breakeven.
-Second, Deuterium is easy to get.
-Third, Tritium is a little annoying to get, but heavy water moderated fission reactors produce the stuff as a waste product, and those aren't going away anytime soon even if we get fusion working. Also, a D+T reactor will be able to breed its own Tritium from waste neutrons and Lithium once it's running. Lithium is easy to get.
" You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever)."
I've said exactly the same thing (the phrase "write X in X") about a) Paul Graham's comparison of Lisp to Python and b) the average C++ programmer's attempts to write anything in anything else. Probably at other times as well, but I don't remember.
I currently know 12 languages[1], and while I'm not a master at all of them, I always do my best to learn to write X in X. This has made me a better programmer in the languages I already use, and has allowed me to discover new favorite languages more than once. Haskell was no exception to this.:)
"I say this from bitter experience. There is many a time when I've had to thread something through a lot of code, and the compiler found every place where it was needed. No, it wasn't pleasant. But it worked first time."
In Python, programs don't tend to involve the degree of recursion that they do in Haskell. Also, it tends to be flatter than Java (eg, you don't end up with subclasses five deep of an abstract class implmenenting some interface), largely because of the dynamic typing and dynamic binding, Typically, restructuring involves adding an argument to a function or set of functions. When one screws this up, it's rarely difficult to track down. I've found that changing the type of an argument is pretty rare (rather, it's removed for some reason and then another is added later for a different reason).
Also, one of the primary reasons for restructuring things in Haskell is also information availability... you need results for something available lower down in the recursing, etc. Much of that is solved by Python's OO-ness. Just have a field with the information.
"On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down."
People say this about Python a lot, However, the problem is easier because there aren't so many types. In C, you've got like const pointers to pointers to char or whatever. In Haskell, everything needs to be passed as an argument, there's no way to get at anything otherwise. In Python, you've got a char object that you pass around freely because it's garbage collected. It doesn't matter if it's const or not because the object is read-only. Then you give it a name like inputChar, and there's very little room for confusion. You don't need large numbers of arguments to functions because most of the time those five chunks of information are available from the one object you passed.
Yes, at the end of the day, Haskell gives you better type safety than just about any language... but that's because it needs it so desperately.
"nested conditionals, well yes, you should use case statements anyway."
Not chained. Nested.
case statements can be useful in preventing chained conditionals if you're looking at a single value, but they can't really help with nested conditionals.
"If you find yourself doing that, you may have written your original program in an imperative style in the first place."
That wasn't the cause. Naturally, this claim is completely impossible to back up without a protracted debate that would require me to post code. I'm not up for that, so I'm just going to leave this here.
"Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes."
Well, this is where good language choice comes in. C can be okay for flat problems, but yes, when it starts getting more complicated, switching to a garbage collected language is usually a pretty good idea.
And, yes, there are times when Haskell is a good language choice. When I say it's "okay", it means I wouldn't be opposed to using it for a problem to which it's well suited. The only language that gets higher praise than that from me is Python.:)
"Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be"
I don't necessarily agree with that.
In OO languages, you often have problems with restructuring, but it's not a fair comparison. Objects have state. That's what they're there for. It's a pain to restructure class hierarchies sometimes, but Haskell can't even solve problem to begin with.
Also, dynamically typed languages like Python also make restructuring easier (using C++/Java as a baseline).
" Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language."
I learn languages because it's impossible to respond to zealots talking about their language of choice otherwise. It usually works pretty well because zealots of languages nobody knows tend to be used to pontificating at people that don't know anything about the language in question. They're not used to people that can respond.
That's why I don't know Perl... lots of people know it, lots of people like it, but no one's going to deffend it.
Haskell is actually okay. The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language. Also, I/O is EXTREMELY counter-intuitive. Because it's functional, it's supposed to be stateless. Wrapping your brain around stateless I/O is hard for most people.
The good thing about it is the patterns. You can provide arbitrarily many implementations of a function, and which one gets evaluated is based on matching the arguments. You can match against arbitrarily many arguments of any type. After you've done this a few times, you feel really dirty using nested conditionals.
Slashdot Mirror
"It's just as secure as OpenBSD, not more."
:)
No, it's not.
-a great deal less of the privsep stuff
-no propolice
-no W^X
A number of vulnerabilities common to NetBSD and OpenBSD were mitigated by ProPolice on OpenBSD. That was 1.6... but I didn't see anything about propolice on the 2.0 release page.
"I can't think of anything more secure then OpenBSD at the moment though."
There are special cases where other OSes can be more secure, IMO. For example, on a big system where you have to let people in with permissions to do something interesting, rather than a firewall or a server spewing pages, the FreeBSD jail facility can make it more secure in practical terms.
There's usually a better OpenBSD way to do it, but that way is sometimes enough of a PITA that it doesn'thappen. For example, you can give someone root in a FreeBSD jail and just let them do their thing rather than screwing around with systrace on an OpenBSD machine. Jails are a very blunt tool, but they're very effective.
Apart from localized advantages such as that, OpenBSD is the most secure. I just didn't want anyone to think I was a zealot blind to the advantages of other OSes.
"Rather, it's just as secure as OpenBSD"
No, it's not.
-a great deal less of the privsep stuff
-no propolice
-no W^X
A number of vulnerabilities common to NetBSD and OpenBSD were mitigated by ProPolice on OpenBSD. That was 1.6... but I didn't see anything about propolice on the 2.0 release page.
This probably hurts open source software...
Gator says "free", Firefox says "free". To someone without access to additional information, there's nothing to tell them apart. To people that are savvy enough to not just install ramdom crap, it probably holds back adoption.
"Why doesn't sun want the code from solaris transfered to linux?"
Linux is the competition.
"That's a serious question because it seems to me if you don't want linux (or freebsd) to benefit from solaris code why did you open source it in the first place. The answer is probably something like "because we want people to code for solaris without getting paid"."
Linux kernel code is virtually never used outside of the Linux kernel. *BSD can't use it, for example, and interviews with developers have indicated that even if they could use it, it would be too much of a PITA to port. I don't see how this is different.
Wow. A heart-felt statement from someone that's not even remotely informed.
Section 2.2: "Conditioned upon Your compliance with Section 3.1 below and subject to third party intellectual property claims, each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license"
Wow. Instead of stopping you from distributing it, they actually explicitly say you can.
Go away.
"Well, maybe they don't know the reasons, maybe they do."
meh. Depends on the manager I guess.
I've been asked to do stuff in Java that was basically the definition of an ideal candidate for Python. Occasionally the Python advantage is so substantial that I'm able to present a completed project almost immediately (eg within a day) that would have taken weeks in Java, but otherwise they don't listen.
Management wants one language that's good at everything, a standard tool so they don't have to look at particulars. That's damaging a lot of the time.
I'm mostly making fun of the concept that any two languages can satisfy a programmer that wants to be able to do a wide range of things, I'm not actually advocating C# or Java, I just picked them because they're the languages that Management likes to use without actually having an idea of the merits of other languages.
"BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter."
C is necessary for enough things that it won't be replaced in our lifetimes. Its use has diminished now that it's not being forced into service for things it was never great at, but it will never be driven out of some areas.
Also, I think it's critical that programmers learn C if only to understand what's going on underneath the newer languages.
Linus is not some kind of deity. He (by his own account) does nothing between kernelspace and small scripts.
I'm very proficient with C, Python and Bash, and I can tell you for a fact: Bash and Python barely compete against each other.
Bash has nothing in the way of nice datatypes. Bash is very slow while Python can be nearly as fast as C (I've gotten it up to 80% when relying heavily on C libraries like regex). Bash can't do more than the most trivial things without helper programs, which while useful, takes forever because it has to keep spawning processes.
For a high level language, Bash has pathetic memory management. Pretty much the only way to get some things done is tempfiles, which is worse than malloc because they're not removed if you don't clean them up.
If you can't hold more than two languages in your head, go home and learn Java and C#. You're only going to get made fun of on slashdot.
Fast or slow, they're using one. Might as well learn to like it.
ahhhhhhhhhhhh
:)
right then
Well, in that case I'm the one that misinterpreted you. I guess I was also wrong about current sources of Tritium. Thanks for the clarification.
Well, because they use an FPGA the card can potentially be reprogrammed to support just enough of OpenGL to do what Quartz Extreme does.
When you think about it, Quartz Extreme only needs to handle a relatively small number of parallel polygons at basically a constant distance away. That's a much simpler job than millions of triangles at arbitrary angles to each other at varying distances and whatnot.
The job the video card does can potentially be as simple as figuring out which window is exposed in a given area and grabbing pixels from the appropriate frame buffer. OpenGL is a good deal more complicated than that, but since both the driver and the FPGA are under our control, I would think it would be possible.
Your mobile does not hit the ground at mach 2.
"the Tritium production comes from putting lithium targets in the reactor for an (n,T) reaction. You will get some tritium from deuterium absorbing neutrons, but that is a real PITA to extract."
Huh?
As you and I both said, a D+T fusion reactor can breed its own Tritium from Lithium and neutrons. However, until the reactor is producing its own Tritium, we need some from elsewhere. It is therefore fortunate that we have fission reactors that produce the stuff anyway.
The current batch of robot probes aren't causing any problems for anyone. The worst thing they leave behind is heat sheilds and parachutes, and the parachutes will be broken down in a few decades by UV radiation from the sun (no free oxygen -> no ozone).
How about a solar thermal tower
The idea is to build a GIANT tower, use solar energy to heat air at the bottom, and then use wind turbines to capture energy from the air as it rises up the tower.
You can put a heat bank at the bottom (probably a lot of water) that releases heat at night. Because it extracts energy from the heat gradient, it still runs fine at night when it's cooler. Also, maintenance on the turbines is easier because they run at one speed in one direction for 50 years.
They've built several prototypes, and results have been good. However, results get better as the tower gets taller, because the air at higher altitude is cooler. This is why the tower has to be so fucking massive.
If they've going to be selling these things to India and China, that'll be a drop in the bucket.
"Is Helium-3 that much easier to fuse and create energy?"
No. It's harder. It requires higher temperatures, and better containment. The only advantage when used for terrestrial uses would be the lower neutron production as compared to reactions like Deuterium-Tritium (D+He3 still produces neutrons from unwanted D+D reactions).
Deuterium-Tritium produces neutrons, but the only radioactive stuff left behind is the reactor itself, and the isotopes in question have shortish half lives (tens of years for the most part). D+T is the only way to go for the forseeable future:
-First, we know we can build a D+T reactor. We know this because we already have. It doesn't produce useful electricity, and requires more work to be economical, but it's the only reaction to acheive breakeven.
-Second, Deuterium is easy to get.
-Third, Tritium is a little annoying to get, but heavy water moderated fission reactors produce the stuff as a waste product, and those aren't going away anytime soon even if we get fusion working. Also, a D+T reactor will be able to breed its own Tritium from waste neutrons and Lithium once it's running. Lithium is easy to get.
er...
1- C, C++, Objective C, Java, Python, {SPARC, x86} assembly, LISP, Haskell, Prolog, Pascal, VB (blearghhh), shell
haha!
:)
" You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever)."
I've said exactly the same thing (the phrase "write X in X") about a) Paul Graham's comparison of Lisp to Python and b) the average C++ programmer's attempts to write anything in anything else. Probably at other times as well, but I don't remember.
I currently know 12 languages[1], and while I'm not a master at all of them, I always do my best to learn to write X in X. This has made me a better programmer in the languages I already use, and has allowed me to discover new favorite languages more than once. Haskell was no exception to this.
"I say this from bitter experience. There is many a time when I've had to thread something through a lot of code, and the compiler found every place where it was needed. No, it wasn't pleasant. But it worked first time."
In Python, programs don't tend to involve the degree of recursion that they do in Haskell. Also, it tends to be flatter than Java (eg, you don't end up with subclasses five deep of an abstract class implmenenting some interface), largely because of the dynamic typing and dynamic binding, Typically, restructuring involves adding an argument to a function or set of functions. When one screws this up, it's rarely difficult to track down. I've found that changing the type of an argument is pretty rare (rather, it's removed for some reason and then another is added later for a different reason).
Also, one of the primary reasons for restructuring things in Haskell is also information availability... you need results for something available lower down in the recursing, etc. Much of that is solved by Python's OO-ness. Just have a field with the information.
"On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down."
People say this about Python a lot, However, the problem is easier because there aren't so many types. In C, you've got like const pointers to pointers to char or whatever. In Haskell, everything needs to be passed as an argument, there's no way to get at anything otherwise. In Python, you've got a char object that you pass around freely because it's garbage collected. It doesn't matter if it's const or not because the object is read-only. Then you give it a name like inputChar, and there's very little room for confusion. You don't need large numbers of arguments to functions because most of the time those five chunks of information are available from the one object you passed.
Yes, at the end of the day, Haskell gives you better type safety than just about any language... but that's because it needs it so desperately.
"nested conditionals, well yes, you should use case statements anyway."
Not chained. Nested.
case statements can be useful in preventing chained conditionals if you're looking at a single value, but they can't really help with nested conditionals.
"If you find yourself doing that, you may have written your original program in an imperative style in the first place."
:)
That wasn't the cause. Naturally, this claim is completely impossible to back up without a protracted debate that would require me to post code. I'm not up for that, so I'm just going to leave this here.
"Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes."
Well, this is where good language choice comes in. C can be okay for flat problems, but yes, when it starts getting more complicated, switching to a garbage collected language is usually a pretty good idea.
And, yes, there are times when Haskell is a good language choice. When I say it's "okay", it means I wouldn't be opposed to using it for a problem to which it's well suited. The only language that gets higher praise than that from me is Python.
"Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be"
I don't necessarily agree with that.
In OO languages, you often have problems with restructuring, but it's not a fair comparison. Objects have state. That's what they're there for. It's a pain to restructure class hierarchies sometimes, but Haskell can't even solve problem to begin with.
Also, dynamically typed languages like Python also make restructuring easier (using C++/Java as a baseline).
" Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language."
I learn languages because it's impossible to respond to zealots talking about their language of choice otherwise. It usually works pretty well because zealots of languages nobody knows tend to be used to pontificating at people that don't know anything about the language in question. They're not used to people that can respond.
That's why I don't know Perl... lots of people know it, lots of people like it, but no one's going to deffend it.
Haskell is actually okay. The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language. Also, I/O is EXTREMELY counter-intuitive. Because it's functional, it's supposed to be stateless. Wrapping your brain around stateless I/O is hard for most people.
The good thing about it is the patterns. You can provide arbitrarily many implementations of a function, and which one gets evaluated is based on matching the arguments. You can match against arbitrarily many arguments of any type. After you've done this a few times, you feel really dirty using nested conditionals.
No, you'd want to run your own irc server.