My previous microwave oven had a knob for intensity and a knob for duration. That's it. You set the intensity, you set the duration, it starts cooking, and it dings when it's done. These were fully analog knobs, no digital electronics of any kind were involved.
When it broke (set itself on fire after twenty years of faithful service), the simplest replacement I could find had a numeric keypad, an LCD display, and a bunch of buttons that I can't read without glasses. It won't work until you tell it what time it is. Every time there's a power glitch, I have to tell the god damned microwave oven what time it is before I can warm up a burrito. I don't intend to use the automatic timer feature, ever. Why would I want an appliance that can potentially set itself on fire to operate when I'm not around? But the thing goes on strike until I set the time.
My previous automatic watering timer had a knob for frequency and a knob for duration. That's it. You set how often it should run, and you set how long it should run, and then you forget about it. These were digital-backed knobs, but knobs nevertheless.
When it broke (valve stuck), the simplest replacement I could find had one knob and a button. The button cycles through a bunch of modes to determine what the knob means. To tell you which mode you are in, there are also a few blinking LEDs that I can't see in bright sunlight or read the labels on without glasses. And guess what, one of the modes is time of day. The old timer got along without knowing the time of day, and this one could too.
In summary, I like knobs, and I don't like appliances that want to know what time it is.
I don't care so much about the actual tags themselves. Letting people tag however they like is the whole point, isn't it?
But I would like to see a single standard API for adding tags and searching for tags. The exact same code should be able to connect to every tag-enabled site. A nice simple REST thing, an HTTP GET to send a query and an XML fragment as result.
I figure there would be two types of query:
1) Send an object identifier (URL, photo id, whatever) and get back a list of tags.
2) Send a tag or list of tags, possibly wildcarded, and get back a list of object identifiers.
One big reason not to get a DSLR: the sensor dust problem. Until someone comes up with a DSLR that fixes this, I'm avoiding them. And it definitely is a fixable problem.
Also, calling any camera with a fixed lens 'point-n-shoot' is rather silly. My camera (DMC-FZ10) has full manual controls and I use them often.
A ten-fold or four-fold increase in traffic - either number assumes that mail admins use spamhaus's list as their one and only spam filter. My guess is such systems are rare to non-existent. In fact what will happen if spamhaus goes away is that the other layers of filtering will take up the slack. Most sites won't even notice the change.
This is nice but fairly wacky. It conflates two separate ideas:
1) Browser-independent toolkit.
2) Java into JavaScript.
The second one no doubt appeals to many, although not to me since I am perfectly comfortable writing JavaScript. On the other hand, I'd love to see Google's take on the all-too-common browser-independent toolkit in *JavaScript*, but apparently I'm not going to!
I get similar accusations fairly often, since I distribute several widely-used freeware httpds. My typical response: "I'm afraid you have misinterpreted what you saw on your screen. Please find someone other than myself to explain it to you before you further embarass yourself." If they come back after that, they go in my mail filter.
If you want an ultra-stable crash-free system, you will need to avoid both Linux and Windows. The choice of programming language and methodology is way down in the noise compared to that.
I bet you could get the same effect by applying a current while brushing your teeth with regular fluoride toothpaste. Maybe Gillette will come out with a toothbrush that has a battery in the handle. Ground return via your hand. Better make sure to use the correct polarity though!
>and three scripting languages (csh, bash, and perl).
Writing scripts in csh is a mistake in any context. I still use csh as my login shell (well, tcsh with some settings changed to make it compatible), and even so I never write scripts in csh, aside from.login and.cshrc.
FreeBSD is not Unix-LIKE, it *is* Unix, in the same sense that Linux is NOT Unix and never will be. FreeBSD is in direct line of descent from the original Unix versions, with continuity of both code and contributors. Linix is a bad re-implementation by a bunch of clueless n00bs who have been re-capitulating all of real Unix's old bugs, twenty years later.
I agree. It doesn't protect against someone specifically targetting your machine, they'll just port-scan you and then proceed on the new port. But it's very effective against the widespread robot attacks we've seen for the past couple of years.
It's a great interview, he tears a lot of folks a new orifice or two. Focus on just the final short paragraph about 'hackers' and you miss the good stuff.
Slashdot Mirror
Since it works on artillery shells too, the other place it would work real well is: Seoul.
My previous microwave oven had a knob for intensity and a knob for duration. That's it. You set the intensity, you set the duration, it starts cooking, and it dings when it's done. These were fully analog knobs, no digital electronics of any kind were involved.
When it broke (set itself on fire after twenty years of faithful service), the simplest replacement I could find had a numeric keypad, an LCD display, and a bunch of buttons that I can't read without glasses. It won't work until you tell it what time it is. Every time there's a power glitch, I have to tell the god damned microwave oven what time it is before I can warm up a burrito. I don't intend to use the automatic timer feature, ever. Why would I want an appliance that can potentially set itself on fire to operate when I'm not around? But the thing goes on strike until I set the time.
My previous automatic watering timer had a knob for frequency and a knob for duration. That's it. You set how often it should run, and you set how long it should run, and then you forget about it. These were digital-backed knobs, but knobs nevertheless.
When it broke (valve stuck), the simplest replacement I could find had one knob and a button. The button cycles through a bunch of modes to determine what the knob means. To tell you which mode you are in, there are also a few blinking LEDs that I can't see in bright sunlight or read the labels on without glasses. And guess what, one of the modes is time of day. The old timer got along without knowing the time of day, and this one could too.
In summary, I like knobs, and I don't like appliances that want to know what time it is.
Too lazy to implement a collaborative filtering / reputation management system.
I did my old FreeBSD systems yesterday. The procedure was as follows:
s rc/share/zoneinfo/northamerica?rev=1.31
/usr/src/share/zoneinfo/northamerica
/usr/src/share/zoneinfo do a 'make install' - this compiles the rules into /usr/share/zoneinfo/.
/usr/share/zoneinfo/ to /etc/localtime.
/etc/localtime in chroot trees, e.g. /etc/bind/. If so, copy the new one there too.
/etc/localtime to the rest.
1) Fetch the new rules file. I got it from:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/
2) Save it as
3) In
4) Run tzsetup - this copies the proper file from
5) Do a 'locate localtime' to see if you have any copies of
If you have multiple identical systems you can do this on one and then copy the new
I don't care so much about the actual tags themselves. Letting people tag however they like is the whole point, isn't it?
But I would like to see a single standard API for adding tags and searching for tags. The exact same code should be able to connect to every tag-enabled site. A nice simple REST thing, an HTTP GET to send a query and an XML fragment as result.
I figure there would be two types of query:
1) Send an object identifier (URL, photo id, whatever) and get back a list of tags.
2) Send a tag or list of tags, possibly wildcarded, and get back a list of object identifiers.
The vibrating sensors are ok but much better solutions are possible.
One big reason not to get a DSLR: the sensor dust problem. Until someone comes up with a DSLR that fixes this, I'm avoiding them. And it definitely is a fixable problem.
Also, calling any camera with a fixed lens 'point-n-shoot' is rather silly. My camera (DMC-FZ10) has full manual controls and I use them often.
BSD Unix: *Really* free software.
A ten-fold or four-fold increase in traffic - either number assumes that mail admins use spamhaus's list as their one and only spam filter. My guess is such systems are rare to non-existent. In fact what will happen if spamhaus goes away is that the other layers of filtering will take up the slack. Most sites won't even notice the change.
I thought of doing this with Cameroon and Colombia about ten years ago.
Anyone care to post a link?
Do you folks ever actually listen to yourselves??
>It's not Free since it allows
Yes, it allows more than the GPL allows. It's more free.
Gnu zealots need to get over themselves.
You know, the one that is actually free instead of just claiming to be free?
This is nice but fairly wacky. It conflates two separate ideas:
1) Browser-independent toolkit.
2) Java into JavaScript.
The second one no doubt appeals to many, although not to me since I am perfectly comfortable writing JavaScript. On the other hand, I'd love to see Google's take on the all-too-common browser-independent toolkit in *JavaScript*, but apparently I'm not going to!
>Mach people (and apparently FreeBSD) are incompetent idiots.
No *you're* a towel.
Yeah, it makes me wonder if RIM has grounds for invalidating the settlement.
And I'm pretty sure I have a RadioMail t-shirt hanging around the attic somewhere.
I get similar accusations fairly often, since I distribute several widely-used freeware httpds. My typical response: "I'm afraid you have misinterpreted what you saw on your screen. Please find someone other than myself to explain it to you before you further embarass yourself." If they come back after that, they go in my mail filter.
If you want an ultra-stable crash-free system, you will need to avoid both Linux and Windows. The choice of programming language and methodology is way down in the noise compared to that.
Use FreeBSD or stay home.
I bet you could get the same effect by applying a current while brushing your teeth with regular fluoride toothpaste. Maybe Gillette will come out with a toothbrush that has a battery in the handle. Ground return via your hand. Better make sure to use the correct polarity though!
>and three scripting languages (csh, bash, and perl).
.login and .cshrc.
Writing scripts in csh is a mistake in any context. I still use csh as my login shell (well, tcsh with some settings changed to make it compatible), and even so I never write scripts in csh, aside from
FreeBSD is not Unix-LIKE, it *is* Unix, in the same sense that Linux is NOT Unix and never will be. FreeBSD is in direct line of descent from the original Unix versions, with continuity of both code and contributors. Linix is a bad re-implementation by a bunch of clueless n00bs who have been re-capitulating all of real Unix's old bugs, twenty years later.
I agree. It doesn't protect against someone specifically targetting your machine, they'll just port-scan you and then proceed on the new port. But it's very effective against the widespread robot attacks we've seen for the past couple of years.
It's a great interview, he tears a lot of folks a new orifice or two. Focus on just the final short paragraph about 'hackers' and you miss the good stuff.
Yeah, I got a note from Alan about this. I will happily concede or at least share the title with him.
He says he has no idea why he gets so much.