Why is proftpd supposedly more secure, though? They are both written in C, and secured by the many-eyeballs (if even) method. As I recall, proftpd has had plenty of remote exploits itself.....
C lang remains inappropriate for network daemons
on
Wu-ftpd Remote Root Hole
·
· Score: 5, Insightful
I know that we sometimes live with legacy code; fair enough. But I claim that it is entirely inappropriate to write security-critical internet daemons in C!
There are lots of people here claiming that this is caused by sloppy or inexperienced programmers. I think that this is bullshit. Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? All of these have had remote overflow (or related) exploits. There are hundreds more... Have you personally ever written a multi-thousand-line network daemon that you know is buffer overflow free? How do you know?
Here is what I say: C the language makes it easy to make the kind of mistake that leads to a remotely exploitable buffer overflow. It is almost as if the language is designed to enable this behavior. According to CERT and others, buffer overflows (and related format-string vulnerabilities, also endemic to C) are the most common source of security holes in UNIX applications (On win32, they are second only to Outlook attachments).
There are only two reasons I can imagine that people would reasonably use C:
Low-level Hardware Access - Fair enough. There are not really any good alternatives now. However, network applications do not need to do low-level hardware access at all.
Raw Speed - Though I believe that other languages are very near to C in performance (http://www.bagley.org/~doug/shootout/craps.shtml) , conventional wisdom says that if you want ultimate speed, use C. However, network applications are not typically CPU-bound, they are network bound. ESPECIALLY FOR THE HOME USER, with a 1.5ghz PC and 5 users per day, this argument is totally silly. Outside the enterprise (where hopefully people can custom tune their software and have people devoted to keeping it secure), there's no reason to need C's speed in a network daemon.
IN A NETWORK APP, SECURITY (SAFETY) IS CRITICAL. That means that all network apps should be written in a language with machine-checked safety. This might mean Java for people who need it to feel like C. (Note that there are several good native code compilers for java, and it has reasonable network support.) In these kinds of languages, buffer overflows and format string vulnerabilities are automatically impossible. Personally, I prefer a more efficient language with stronger safety guarantees: SML. (Ocaml might suit the slashdot audience better) In fact, at the time of the last wu_ftpd remote root exploit, I decided that it was time for me to rewrite my ftp daemon in SML. It took me only 1 weekend to get it working, by myself. It does not support every feature of FTP (especially obsolete things and dubious "features" like SITE EXEC), though it supports plenty for say, the average linux desktop user. Writing code in a modern, high-level language has other benefits too: it is only about 3000 lines, including library code that I wrote to implement MD5 passwords and various other things that I plan to use in other daemons (the core ftp server is only 850 lines). Compare this to wu_ftpd (8000+ lines) and the PAM MD5 password implementation (200 lines). Most importantly, I know that by using a safe language that I have a 100% buffer overflow free daemon. Thus, I can spend more time looking over the code for more subtle security problems, such as possibilities for Denial of Service attacks. (I didn't do much of this, actually, though it is not vulnerable to the ls globbing attack, SITE EXEC, or PAM authentication bugs that have been in other ftp servers.)
If you think this sounds good, you can get my FTP server here and an ML compiler here. (It is just a proof of concept, so don't get too excited!) But what I would rather you do is just listen to my advice, and demand better from your software manufacturer! Linux distributions that want to be secure should be rewriting this kind of software in some modern safe language. It is easy to do, and the results are worthwhile.
This is a terrible argument. Of course, anything is safe (anthrax?) if you don't do dangerous things with it.
Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? (the list continues...) No, not most of them. The simple fact is that C makes it easy to make mistakes that lead to exploitable security holes.
> It may be very nice in many ways. When I've looked
> at it I've been interested in reading in
> self-identifying objects from files.
By objects, presumably you mean programming objects -- bits of code and data. I think this is kind of a weird thing to want to do (I can imagine some circumstances, but not many, where you wouldn't have your whole program written before running it), so I personally don't know how to do it, and it may be that highly compiled languages like caml are just in the wrong domain for this kind of dynamic behavior. However, I do know that caml lets you dynamically load and link bytecode-compiled modules, so it is possible that you could do it rather cleanly through that facility.
> you still need to be able to listen to the packets
> during transmission - which (for anyone outside of
> a NOC) is extremely difficult. I'm guessing that
> troop movements would be similarly hard to get
> access to.
You're right that there is something to consider here, but I don't think this is as hard as it sounds. Just think how easily the Nimda and Code Red worms spread (or how common buffer overflows are in unix daemons, too) -- all you need is control of a machine on the target machine's local network to sniff packets.
Well, I'm sure that people use it to protect (encrypt) copyrighted works, but I think you'd be hard pressed to really find a situation where 3DES is the thing which *controls access* to a copyrighted work. Basically, the intent of the relevant section of the law is exactly to protect movie companies from DeCSS. (Though, they were thinking about hardware devices more than they were thinking about software tools, which is why there has been the great speech vs. device debate.)
I'm pretty sure the original paper (by Curry I think) had a J combinator that acted similarly, but this definition is nice and easy to remember... neat!
I'm curious. What about perl is easy to understand?
I think I would agree that, say, the core of scheme is lightweight according to your
You didn't claim that perl is a lightweight language, but those at the conference seem to think it is. To me, perl is quite complicated, since there is so much implicit activity meant to make certain things briefer or automatic. I am thinking in particular of its rules about automatic conversion in various contexts. (I suppose it usually does the right thing, but the ease of understanding why something is wrong falls into the "easy to understand" category for me!)
Maybe, "languages for writing throwaway programs for small tasks?"
> You don't get to the cutting edge of programming
> lanugage implementation by wasting your time
> reading the many years of esoteric research
> published on the subject, especially since real
> languages frequently have to do things that don't
> make for terribly fascinating research.
Of course this is true, but I am not asking anyone to waste years on *esoteric* research. I am merely proposing that people designing a new OS or programming language look at the current state of the art; to at least know about and consider seriously the *known good ideas* in academia.
Here are some glaring examples of features that ML (for instance) has that are *damn useful*, totally not esoteric, yet typically don't even find their way to the table in the design of a slashdot programming language:
- parametric polymorphism. (No casts!! Java is slowly getting this, finally; they call it "generics").
- datatypes and pattern matching. (Makes processing recursive data structure like lists and parse trees beautifully simple!)
There are many other things I can think of, which have varying degrees of obscurity, but I think these two are firmly on the useful side.
My point is that people somehow bizarrely confuse "popular" with "state of the art". Like, in a slashdot discussion about programming languages, I invariably hear, "X is better than Y because X is object-oriented," as if object-oriented programming is the pinnacle of PL design. It's 30 years old! (Even the ideas I propose above are about that old!) It is worth looking at more recent ideas, and those aren't typically to be found in mainstream programming languages.
> You don't think that would be considered trafficking in a security circumvention device?
The DMCA doesn't outlaw the trafficking of a security circumvention device. Only tools which circumvent access to a *copyrighted work*. I agree that it's a bad law, but we should be careful about what it actually covers.
It's not that hard to make it really expensive to forge votes. For instance, check out the captcha project at CMU. (Basically, it generates images that are difficult for a computer to recognize, but easy for a human, and challenges the user to respond to them in some way to prove that they are human.) If they could find the right balance of convenience for humans and difficulty for perl scripts, I think they'd have a great thing going. I have always wanted this feature in a search engine... I'm glad to see it happen.
> Heh, your notion of "relatively easy" and "not
> as nice" must be somewhat different from mine...
Well, maybe I think differently. I really do think it is easier than at least the example I was replying to, since it is possible in the lambda calculus to write a piece of code once, and then bind it to a variable, and then use it anywhere you like. (So I could write Zero and Successor and Plus and If and True once, and slowly build up a much more useful programming language.)
> Are you talking about the IJ basis for the > lambda calculus?
I was talking about the S and K combinators, which are these closed functions:
K x y = x
S x y z = (x z)(y z)
It turns out you can rewrite any lambda calculus program, and thus, any computable function, with just these! (One of the neatest things I've ever learned...)
Caml does full type inference for you, so that you have to write fewer types than you would in C or java.
In fact, in Caml you really only have to write types when you write down an interface to a module -- and this is exactly what languages without sophisticated type systems lack. It is very difficult to write precisely what your interface is without writing down types, and if the type language is poor (ie, Java, or worse: perl) then writing interfaces becomes more an exercise in documentation and finger-crossing.
(Personally, I also find that automatic type checking is very conducive to writing maintainable programs. It keeps me from making the gross hacks that are so tempting in perl. Typically it doesn't make my programs any longer or more difficult to write, since ML-family languages have lots of features to capture the common idioms that require this "flexibility" in perl et al.)
Careful not to make too many generalizations. I think Caml is much nicer than other typed languages you mention.
I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems... but not very interested in working out all the implications.
This is the best paragraph in the article. Here's what makes me sad:
Slashdot-type hackers have an amazing ability to get things done. They can really come up with a working product faster than anyone.
BUT, slashdot-type hackers have a tendency to implement olddd ideas, and also frequently to make well-understood mistakes. It is true that we are on the cutting edge of implementing internet protocols and maybe window managers, but in other areas we are implementing 30 year-old ideas still. (OS design and programming languages come to mind especially.)
WHO, if not the hackers, will embrace this stuff? They are the only ones that are supposed look beyond the hype and marketing and status quo to evaluate things based on technical merits, and to create implementations of new ideas.
I know only the OS design that I learned in my undergraduate course. But that is enough to know that the design of the kernel is very conservative! Where are capabilities? Where is fine-grained access control? Does anybody *really* think that their internet daemons should run as *root* just so they can open up a port with a low number? (I know there are plenty of workarounds...) I am sure that there are dozens of great ideas in OS design from the last 20 years that would be totally appropriate for a hacker's kernel.
I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?
(So, the PL fanatic in me wants to point out caml, which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers. It is really fast -- probably the fastest, it is hacker buzzword-compliant (it has "objects"), and yet it has taken many great ideas from academia and put them in a really usable, accessible form. Try it if you are in for a taste of something different!)
Anyway, just trying to say that if you are tempted to go hack up your own programming language, please at least don't assume that Perl is the state of the art because it is the most popular scripting language or something. Take a class, read a book, and check out some of the weirder languages coming out of academia first. Hackers are how the revolution happens...
Re:Whats the "lighest" you can get?
on
Lightweight Languages
·
· Score: 5, Informative
Well, we can see that you learned to program in BASIC.;) Not all languages need assignment as their primary form of computation...
I'd say that the lambda calculus is more lightweight, and also easier to program in than your example:
exp::= x (variable)
| exp1 exp2 (application)
| (fn x => exp) (function)
Basically the key is that you have higher-order functions (you can pass them around), and that's it. With this, it's relatively easy to code up booleans, integers, lists, recursive functions, trees, or practically anything. (If you wanted to do IO, you'd need some kind of primitive functions for interfacing with the machine.) Since everything is higher-order, it's easy to code these once and then pass them around. It's not as nice as a modern language, but it's nicer than a turing machine...
Actually, there is a simpler language that uses only two functions (!), but this one is pretty hard to program in directly.
The headphones that come with it are quite small, and not that bad for small ones, but you'll get much better sound out of real headphones.(My current headphones are unfortunately much larger than the rio itself!) The worst thing about the headphones is that they almost seem *designed* to tangle... I've never pulled them out of my pocked and had them not be tied into some impossible knot.
The USB interface rocks (for win, at least).
Bundled software is crappy, but usable.
Yes, battery life is awesome.
I think your battery clip might have lost its spring... I had to bend mine out a little more recently. My RIO is totally shockproof; I drop it all the time.
It's true that the sampling rate at 44khz is just about enough to cover the nyquist of human hearing (about 20khz, so they say). But this doesn't say anything about the sampling resolution. You could sample at 44hkz but use 4 bits per sample, and the result would be awful. 16 bits is pretty damn good, but it is not perfect. (And it doesn't help that it is spread linearly over the range. 32-bit floating point sounds much nicer.)
Anyway, I say that CDs sound pretty good, personally, though I do wish that it wasn't so common to compress (as in, flatten out the dynamics, not as in MP3) them so much. If they didn't do this (DVD audio typically doesn't), I think they would sound as good as LPs (and be much more convenient and robust).
Look, I was just explaining how it happens. I point out ways to avoid this in a later paragraph. Let's direct that anger towards something more productive, ok?
People often wonder how their "secret" sites get into web indices. Here's a scenario that's not too obvious but is quite common:
Suppose I have a secret page, like:
http://mysite.com/cgi-bin/secret?password=admini st rator
Suppose this page has some links on it, and someone (maybe me, maybe my manager) clicks them to go to another site (http://elsewhere.com/).
Now suppose elsewhere.com runs analog on their web logs, and posts them in a publically-accessible location. Suppose elsewhere.com's analog setup also reports the contents of the "referer" header.
Now suppose the web logs are indexed (because of this same problem, or because the logs are just linked to from their web page somewhere). Google has the link to your secret information, even though you never explicitly linked to it anywhere.
One solution is to use proper HTTP access control (as crappy as it is), or to use POST instead of GET to supply credentials (POST doesn't transfer into a URL that might be passed as a referrer). You could also use robots.txt to deny indexing of your secret stuff, though others could still find it through web logs.
Of course, I don't think credit card info should *ever* be accessible via HTTP, even if it is password protected!
Having had the distinct displeasure of working with MS SQL before, I think I can lend some insight into why SQL server gets installed with no sa password.
There are lots of companies out there that make custom software, or domain-specific software, and sell it for lots of money. Most of the software they make is database stuff for busineses, (so, there might be a company that specializes in a database product for food manufacturers, etc.).
These apps, if they are for NT, usually need MS SQL server. Usually, the person installing them doesn't know anything about SQL server, they just bought it for the first time along with the app. The installation instructions tell them to do a certain thing, they do it, and viola, SQL server is installed with a default or empty password. (To their credit, the versions of MS SQL I've used are very happy to install without setting a password for the administrator.) Most of these people probably don't realize that the software can be accessed over TCP/IP. After all, remote accessibility over the internet in Windows is a relatively new thing (as opposed to the UNIX world).
So yes, this is stupid, but it is not as braindead as installing redhat and stubbornly skipping the step where it asks you to choose a root password. You have to understand what SQL server is about, which is not as common as it perhaps should be, because SQL server is typically seen as an *accessory* to the real app they are installing.
There is a lot of stupid custom software written that needs MS SQL server with an admin account that has an empty or fixed password. I have installed this stuff before.
It's crappy stuff, but I don't pick it, and I don't think I have the business understanding to know how to pick something better that is still useful to the company.
All you can do is try to turn off remote access or firewall the thing...
Slashdot Mirror
Why is proftpd supposedly more secure, though? They are both written in C, and secured by the many-eyeballs (if even) method. As I recall, proftpd has had plenty of remote exploits itself.....
I know that we sometimes live with legacy code; fair enough. But I claim that it is entirely inappropriate to write security-critical internet daemons in C!
There are lots of people here claiming that this is caused by sloppy or inexperienced programmers. I think that this is bullshit. Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? All of these have had remote overflow (or related) exploits. There are hundreds more... Have you personally ever written a multi-thousand-line network daemon that you know is buffer overflow free? How do you know?
Here is what I say: C the language makes it easy to make the kind of mistake that leads to a remotely exploitable buffer overflow. It is almost as if the language is designed to enable this behavior. According to CERT and others, buffer overflows (and related format-string vulnerabilities, also endemic to C) are the most common source of security holes in UNIX applications (On win32, they are second only to Outlook attachments).
There are only two reasons I can imagine that people would reasonably use C:
Low-level Hardware Access - Fair enough. There are not really any good alternatives now. However, network applications do not need to do low-level hardware access at all.
Raw Speed - Though I believe that other languages are very near to C in performance (http://www.bagley.org/~doug/shootout/craps.shtml) , conventional wisdom says that if you want ultimate speed, use C. However, network applications are not typically CPU-bound, they are network bound. ESPECIALLY FOR THE HOME USER, with a 1.5ghz PC and 5 users per day, this argument is totally silly. Outside the enterprise (where hopefully people can custom tune their software and have people devoted to keeping it secure), there's no reason to need C's speed in a network daemon.
IN A NETWORK APP, SECURITY (SAFETY) IS CRITICAL. That means that all network apps should be written in a language with machine-checked safety. This might mean Java for people who need it to feel like C. (Note that there are several good native code compilers for java, and it has reasonable network support.) In these kinds of languages, buffer overflows and format string vulnerabilities are automatically impossible. Personally, I prefer a more efficient language with stronger safety guarantees: SML. (Ocaml might suit the slashdot audience better) In fact, at the time of the last wu_ftpd remote root exploit, I decided that it was time for me to rewrite my ftp daemon in SML. It took me only 1 weekend to get it working, by myself. It does not support every feature of FTP (especially obsolete things and dubious "features" like SITE EXEC), though it supports plenty for say, the average linux desktop user. Writing code in a modern, high-level language has other benefits too: it is only about 3000 lines, including library code that I wrote to implement MD5 passwords and various other things that I plan to use in other daemons (the core ftp server is only 850 lines). Compare this to wu_ftpd (8000+ lines) and the PAM MD5 password implementation (200 lines). Most importantly, I know that by using a safe language that I have a 100% buffer overflow free daemon. Thus, I can spend more time looking over the code for more subtle security problems, such as possibilities for Denial of Service attacks. (I didn't do much of this, actually, though it is not vulnerable to the ls globbing attack, SITE EXEC, or PAM authentication bugs that have been in other ftp servers.)
If you think this sounds good, you can get my FTP server here and an ML compiler here . (It is just a proof of concept, so don't get too excited!) But what I would rather you do is just listen to my advice, and demand better from your software manufacturer! Linux distributions that want to be secure should be rewriting this kind of software in some modern safe language. It is easy to do, and the results are worthwhile.
> Hardly. C, used properly, is a safe language.
This is a terrible argument. Of course, anything is safe (anthrax?) if you don't do dangerous things with it.
Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? (the list continues...) No, not most of them. The simple fact is that C makes it easy to make mistakes that lead to exploitable security holes.
> It may be very nice in many ways. When I've looked
> at it I've been interested in reading in
> self-identifying objects from files.
By objects, presumably you mean programming objects -- bits of code and data. I think this is kind of a weird thing to want to do (I can imagine some circumstances, but not many, where you wouldn't have your whole program written before running it), so I personally don't know how to do it, and it may be that highly compiled languages like caml are just in the wrong domain for this kind of dynamic behavior. However, I do know that caml lets you dynamically load and link bytecode-compiled modules, so it is possible that you could do it rather cleanly through that facility.
> you still need to be able to listen to the packets
> during transmission - which (for anyone outside of
> a NOC) is extremely difficult. I'm guessing that
> troop movements would be similarly hard to get
> access to.
You're right that there is something to consider here, but I don't think this is as hard as it sounds. Just think how easily the Nimda and Code Red worms spread (or how common buffer overflows are in unix daemons, too) -- all you need is control of a machine on the target machine's local network to sniff packets.
Well, I'm sure that people use it to protect (encrypt) copyrighted works, but I think you'd be hard pressed to really find a situation where 3DES is the thing which *controls access* to a copyrighted work. Basically, the intent of the relevant section of the law is exactly to protect movie companies from DeCSS. (Though, they were thinking about hardware devices more than they were thinking about software tools, which is why there has been the great speech vs. device debate.)
I'm pretty sure the original paper (by Curry I think) had a J combinator that acted similarly, but this definition is nice and easy to remember... neat!
ehehe... gotta love a language where "till" (as in "wait till") is a keyword. ;)
I'm curious. What about perl is easy to understand?
I think I would agree that, say, the core of scheme is lightweight according to your
You didn't claim that perl is a lightweight language, but those at the conference seem to think it is. To me, perl is quite complicated, since there is so much implicit activity meant to make certain things briefer or automatic. I am thinking in particular of its rules about automatic conversion in various contexts. (I suppose it usually does the right thing, but the ease of understanding why something is wrong falls into the "easy to understand" category for me!)
Maybe, "languages for writing throwaway programs for small tasks?"
> You don't get to the cutting edge of programming
> lanugage implementation by wasting your time
> reading the many years of esoteric research
> published on the subject, especially since real
> languages frequently have to do things that don't
> make for terribly fascinating research.
Of course this is true, but I am not asking anyone to waste years on *esoteric* research. I am merely proposing that people designing a new OS or programming language look at the current state of the art; to at least know about and consider seriously the *known good ideas* in academia.
Here are some glaring examples of features that ML (for instance) has that are *damn useful*, totally not esoteric, yet typically don't even find their way to the table in the design of a slashdot programming language:
- parametric polymorphism. (No casts!! Java is slowly getting this, finally; they call it "generics").
- datatypes and pattern matching. (Makes processing recursive data structure like lists and parse trees beautifully simple!)
There are many other things I can think of, which have varying degrees of obscurity, but I think these two are firmly on the useful side.
My point is that people somehow bizarrely confuse "popular" with "state of the art". Like, in a slashdot discussion about programming languages, I invariably hear, "X is better than Y because X is object-oriented," as if object-oriented programming is the pinnacle of PL design. It's 30 years old! (Even the ideas I propose above are about that old!) It is worth looking at more recent ideas, and those aren't typically to be found in mainstream programming languages.
> You don't think that would be considered trafficking in a security circumvention device?
The DMCA doesn't outlaw the trafficking of a security circumvention device. Only tools which circumvent access to a *copyrighted work*. I agree that it's a bad law, but we should be careful about what it actually covers.
It's not that hard to make it really expensive to forge votes. For instance, check out the captcha project at CMU. (Basically, it generates images that are difficult for a computer to recognize, but easy for a human, and challenges the user to respond to them in some way to prove that they are human.) If they could find the right balance of convenience for humans and difficulty for perl scripts, I think they'd have a great thing going. I have always wanted this feature in a search engine
> Heh, your notion of "relatively easy" and "not
> as nice" must be somewhat different from mine...
Well, maybe I think differently. I really do think it is easier than at least the example I was replying to, since it is possible in the lambda calculus to write a piece of code once, and then bind it to a variable, and then use it anywhere you like. (So I could write Zero and Successor and Plus and If and True once, and slowly build up a much more useful programming language.)
> Are you talking about the IJ basis for the > lambda calculus?
I was talking about the S and K combinators, which are these closed functions:
K x y = x
S x y z = (x z)(y z)
It turns out you can rewrite any lambda calculus program, and thus, any computable function, with just these! (One of the neatest things I've ever learned...)
Caml does full type inference for you, so that you have to write fewer types than you would in C or java.
In fact, in Caml you really only have to write types when you write down an interface to a module -- and this is exactly what languages without sophisticated type systems lack. It is very difficult to write precisely what your interface is without writing down types, and if the type language is poor (ie, Java, or worse: perl) then writing interfaces becomes more an exercise in documentation and finger-crossing.
(Personally, I also find that automatic type checking is very conducive to writing maintainable programs. It keeps me from making the gross hacks that are so tempting in perl. Typically it doesn't make my programs any longer or more difficult to write, since ML-family languages have lots of features to capture the common idioms that require this "flexibility" in perl et al.)
Careful not to make too many generalizations. I think Caml is much nicer than other typed languages you mention.
I think we learned that many problems that we're facing in terms of Perl implementation right now have already been thoroughly researched and dealt with as many as 30 years ago; but we also learned that if we want to get at this research, then we need to do a lot of digging. The academic community is good at solving tricky problems ... but not very interested in working out all the implications.
This is the best paragraph in the article. Here's what makes me sad:
Slashdot-type hackers have an amazing ability to get things done. They can really come up with a working product faster than anyone.
BUT, slashdot-type hackers have a tendency to implement olddd ideas, and also frequently to make well-understood mistakes. It is true that we are on the cutting edge of implementing internet protocols and maybe window managers, but in other areas we are implementing 30 year-old ideas still. (OS design and programming languages come to mind especially.)
WHO, if not the hackers, will embrace this stuff? They are the only ones that are supposed look beyond the hype and marketing and status quo to evaluate things based on technical merits, and to create implementations of new ideas.
I know only the OS design that I learned in my undergraduate course. But that is enough to know that the design of the kernel is very conservative! Where are capabilities? Where is fine-grained access control? Does anybody *really* think that their internet daemons should run as *root* just so they can open up a port with a low number? (I know there are plenty of workarounds...) I am sure that there are dozens of great ideas in OS design from the last 20 years that would be totally appropriate for a hacker's kernel.
I know a bit more about PL design. Being in academia pollutes the mind, I know, but I am sure that almost all I see in the slashdot PL community is reworking of old, mediocre ideas. Who in the world will use and develop new programming languages if not hackers?
(So, the PL fanatic in me wants to point out caml, which, even though it is not my personal favorite, I think could become really popular with slashdot-style hackers. It is really fast -- probably the fastest, it is hacker buzzword-compliant (it has "objects"), and yet it has taken many great ideas from academia and put them in a really usable, accessible form. Try it if you are in for a taste of something different!)
Anyway, just trying to say that if you are tempted to go hack up your own programming language, please at least don't assume that Perl is the state of the art because it is the most popular scripting language or something. Take a class, read a book, and check out some of the weirder languages coming out of academia first. Hackers are how the revolution happens...
Well, we can see that you learned to program in BASIC. ;) Not all languages need assignment as their primary form of computation ...
::= x (variable)
I'd say that the lambda calculus is more lightweight, and also easier to program in than your example:
exp
| exp1 exp2 (application)
| (fn x => exp) (function)
Basically the key is that you have higher-order functions (you can pass them around), and that's it. With this, it's relatively easy to code up booleans, integers, lists, recursive functions, trees, or practically anything. (If you wanted to do IO, you'd need some kind of primitive functions for interfacing with the machine.) Since everything is higher-order, it's easy to code these once and then pass them around. It's not as nice as a modern language, but it's nicer than a turing machine...
Actually, there is a simpler language that uses only two functions (!), but this one is pretty hard to program in directly.
The headphones that come with it are quite small, and not that bad for small ones, but you'll get much better sound out of real headphones.(My current headphones are unfortunately much larger than the rio itself!) The worst thing about the headphones is that they almost seem *designed* to tangle... I've never pulled them out of my pocked and had them not be tied into some impossible knot.
The USB interface rocks (for win, at least).
Bundled software is crappy, but usable.
Yes, battery life is awesome.
I think your battery clip might have lost its spring... I had to bend mine out a little more recently. My RIO is totally shockproof; I drop it all the time.
I would probably guess that the response of the needle is not really linear (since it is a physical device), but I don't know enough to say for sure.
It's true that the sampling rate at 44khz is just about enough to cover the nyquist of human hearing (about 20khz, so they say). But this doesn't say anything about the sampling resolution. You could sample at 44hkz but use 4 bits per sample, and the result would be awful. 16 bits is pretty damn good, but it is not perfect. (And it doesn't help that it is spread linearly over the range. 32-bit floating point sounds much nicer.)
Anyway, I say that CDs sound pretty good, personally, though I do wish that it wasn't so common to compress (as in, flatten out the dynamics, not as in MP3) them so much. If they didn't do this (DVD audio typically doesn't), I think they would sound as good as LPs (and be much more convenient and robust).
> Or you could just suck.
Look, I was just explaining how it happens. I point out ways to avoid this in a later paragraph. Let's direct that anger towards something more productive, ok?
People often wonder how their "secret" sites get into web indices. Here's a scenario that's not too obvious but is quite common:
i st rator
Suppose I have a secret page, like:
http://mysite.com/cgi-bin/secret?password=admin
Suppose this page has some links on it, and someone (maybe me, maybe my manager) clicks them to go to another site (http://elsewhere.com/).
Now suppose elsewhere.com runs analog on their web logs, and posts them in a publically-accessible location. Suppose elsewhere.com's analog setup also reports the contents of the "referer" header.
Now suppose the web logs are indexed (because of this same problem, or because the logs are just linked to from their web page somewhere). Google has the link to your secret information, even though you never explicitly linked to it anywhere.
One solution is to use proper HTTP access control (as crappy as it is), or to use POST instead of GET to supply credentials (POST doesn't transfer into a URL that might be passed as a referrer). You could also use robots.txt to deny indexing of your secret stuff, though others could still find it through web logs.
Of course, I don't think credit card info should *ever* be accessible via HTTP, even if it is password protected!
They like it cos they're communists!
One word.... LASERS.
Having had the distinct displeasure of working with MS SQL before, I think I can lend some insight into why SQL server gets installed with no sa password.
There are lots of companies out there that make custom software, or domain-specific software, and sell it for lots of money. Most of the software they make is database stuff for busineses, (so, there might be a company that specializes in a database product for food manufacturers, etc.).
These apps, if they are for NT, usually need MS SQL server. Usually, the person installing them doesn't know anything about SQL server, they just bought it for the first time along with the app. The installation instructions tell them to do a certain thing, they do it, and viola, SQL server is installed with a default or empty password. (To their credit, the versions of MS SQL I've used are very happy to install without setting a password for the administrator.) Most of these people probably don't realize that the software can be accessed over TCP/IP. After all, remote accessibility over the internet in Windows is a relatively new thing (as opposed to the UNIX world).
So yes, this is stupid, but it is not as braindead as installing redhat and stubbornly skipping the step where it asks you to choose a root password. You have to understand what SQL server is about, which is not as common as it perhaps should be, because SQL server is typically seen as an *accessory* to the real app they are installing.
There is a lot of stupid custom software written that needs MS SQL server with an admin account that has an empty or fixed password. I have installed this stuff before.
It's crappy stuff, but I don't pick it, and I don't think I have the business understanding to know how to pick something better that is still useful to the company.
All you can do is try to turn off remote access or firewall the thing...