0. someone should've been paying attention when Verisign- the self-proclaimed "leeders" in Internet security- signed a code-signing certificate for Microsoft.... for someone who wasn't Microsoft.
1. people shouldn't be entering credit card or login information into a page that they clicked on from an email.
2. unicode should've been arranged by glyph similarity instead of by script family.
3. people shouldn't cry about having a domain name "in their script." - domain names are _supposed_ to be easy to type, and easy to remember. IDNs are neither to people foreign to that script, and often, neither to people even USING that script.
4. people should've been less afraid of bookmarks.
A question [possibly addressed by the book]
on
Blink
·
· Score: 5, Interesting
I understand this behavior because I see it; Our very own Fearless Leader exhibits this "thin slicing" with a remarkable success rate.
I do a significant amount of research in an effort to predict certain kinds of market trends and behaviors but what bothers me is that he [often] gets the same results without that work.
Nevertheless, I wonder mostly, why he is dismissive of a technical method that produces his results. Sometimes, it produces different results, and for those times he is extremely grateful, but when it doesn't- that is, when a technical and exhaustive method yields the same result as his snap decisions, he is very frustrated that the technical method was performed at all.
Like it's "obvious" to those of us without the manager hair and posture...
Consider getting a cordless presentation mouse. The kind that doesn't need a surface and either rocks, or has a knob on it for use. You can get 'em at staples for pretty cheap and they do work.
I prefer the Thinkpad nipple, and abhor the touchpad -and-go-the-opposite-way. The presentation mice work as a weak substitute.
Whoever you look at, call their support desk try reciting scenarios described in BOFH articles. Pick something obscene. Tell them you have put seeds and jam in your cdrom tray and need to get your website back up.
You'll know you found a good place when the support desk has actually been there.
10$/month hosting companies simply haven't. Even most 20$/month companies don't.
They have an answering service that takes a message. They'll probably email you later if they bother helping at all. They'll probably ignore you because jam and seeds aren't that funny.
In fact, there are very few 20$/month hosting companies that even have a hand in their own servers. Be wary of a company that can't support themselves.
LARGE businesses CAN do the cost analysis. They CAN think 30 years in the future. They CAN see that increasing everyones' typing rate 5wpm over the course of 30 years DOES make them money.
The problem is that changing keyboards does NOT increase typing rate EVEN 5wpm (across the board), and it doesn't translate into greater productivity.
If someone DOES come up with a keyboard that is guaranteed to make an old fart like me type faster with less hand/wrist pain when acclimated - there is no doubt that the world will switch.
So to keyboard inventors everywhere: If you come up with a great idea, and it doesn't seem to be catching on: Don't do what DVORAK did and invent a whole bunch of "studies" that can't be reproduced.
Instead, go try and invent another keyboard layout. You might be on to something with the first one, but it obviously isn't right (yet).
I am a capable DVORAK typist (0%err.approx. 45-55 wpm), and an excellent QWERTY typist (0%err.approx. 80-95 wpm).
I also suffer from incredible wrist and forearm pains from typing too long (or too fast).
Other hackers should be able to attest to this: under a good hacking session, that "0% error approximate" typing rate can go up quite a bit. I've had bursts of 5-12 minutes of well over 120wpm, with zero error.
I try and minimize those moments (when I notice they are happening) because it usually means my forearms are about to swell up and my wrists are about to stop responding without severe pains.
At first, when I was learning DVORAK I never had any pains- but I assumed this was because of the low typing speed, and in a way, I was right.
As I started picking up speed (and entering hack-mode in DVORAK), I noticed the pains coming. But even while barely reaching 45wpm in DVORAK, it was still hurting in about the same amount of time as my 85wpm QWERTY.
You see, when typing DVORAK, my hands certainly don't do much travelling, but I end up with enormous bias- using my left hand for several characters in a row, then getting a single right-hand key, before going back to the left hand. This lack of hand-travel definately contributed to learning how to type DVORAK very quickly.
When using QWERTY, on the other hand, my hands do MORE travelling (more still because of vi's escape-key fetish) but I find I'm using both hands more evenly. I've noticed that hand travel (however) doesn't stop my typing; i.e. my left hand will travel while my right is still typing.
Some say I can improve my DVORAK speed, and surely I know many folks that say their highest DVORAK speed is higher than their highest QWERTY speed. I also know of many more who haven't found any discernable difference in "top speed".
But note that I'm deliberately keeping my QWERTY speed down, as going MUCH too fast accelerates the pains.
Since DVORAK "hurts" at 50wpm where QWERTY "hurts" at 90wpm, I think it's easy to see why I use QWERTY to avoid hand/wrist pains.
of course they have a sense of humor. don't you see the full-page jokes they publish in IT journals?
0$ > 6000$
0$ > 9000$
0$ > 13000$
100Mbit network + 2000$ Windows 2003 PC is CHEAPER than a 100Mbit network + 60,000$ mainframe running linux! THEREFORE Windows 2003 PC is CHEAPER than running Linux!
"In many cases the response is we need to stick with the version that's available at the time that we purchased that distribution, so for example if I'm running Apache 1.3 on my Red Hat Enterprise server, although I may want Apache 2.0 because it might have new features or it might have some new capabilities, I'm outside of my support model now with Red Hat."
Is this a bad thing? Does Microsoft do something different? Can I get IIS6 supported on Windows 2000? Can I get Apache2 supported on Windows 2000?
"... if you take a look at Intertrust, the company that filed suit against Microsoft for patent infringement, Microsoft wrote a check for $440 million and our customers did not have to do anything in their implementation of Microsoft technology nor feel the pain, let's just say, of that situation."
If I used Microsoft software (That's a pretty big IF), would anything be different for me if Microsoft DIDN'T pay off Intertrust? Does Microsoft really think that if I don't violate a patent, I can be sued because they did?
"Obviously, Microsoft is incredibly focused on security."
1. select()ing files actually demands that read() not block.
2. shadowlink() which allows for rename()ing the original to atomically update the shadow()
3. rename()ing a file into a directory that's opened has it's entry added to the end of the readdir() queue for that other process IF the original name hasn't been seen in that directory [yet]
4. join(a,b) syscall which attaches directory b's contents into directory a for this process and all children. a complementary unjoin(a) and unjoin2(a,b) which remove all joins, and a specific join respectively.
5. fork() return a file descriptor. writing to the file descriptor sends that signal. reading from the descriptor wait()s for it's status. close()ing the file descriptor detaches. if you really wanted to, getfpid(f) returns the opaque pid of the peer on f. getpfid(p) does the reverse. getpfid(-1) or 0 returns the file descriptor for the current process.
6. splitsocket(s,&i,&o) returns a pair of ofiles. reading from i is the same as reading from s. writing to o is the same as writing to s. closing i is the same as shutdown(SHUT_RD); closing o is the same as shutdown(SHUT_WR); closing(s) after splitsocket() does nothing.
7. poll2() which uses struct poll2s which are a linked list and have a void*userv; for user data.
8. disablenetwork() which kills the current process and any child processes ability to use routable network traffic.
9. bootnumber() and poweronseq() which return the number of boots this system has had and the number of times poweronseq() has been called by any process. these together can be used for sequence number generation.
10. daemons are stupid. let the shell background them.
11. seek() on a pipe will generate a SIGPIPESEEK on the peer if the peer handles it (default/ignore is to generate the normal error with no side effects). that signal has in its sigaction the desired offset.
12. postfd(f) returns a 1024-byte random token that another process can use getfd(tok) to get that fd without using any other communication channel.
13. mapf(addr,len) creates a file descriptor from the current process address space. mmap()ing that fd can reobtain that address space - even after exec().
14. insist csh be never again used for programming.
15. audit(f); system call which raises SIGSTOP for this process (and all children) whenever they do an operation that touches f. if f is a directory, then this includes all children of f, ignoring symlinks. a debugger can notice this.
16. anonf(x) returns a file descriptor that is backed by some inaccessible file space without a name. if x is >-1 then it will be on the same filesystem as "x" is, and thus flink() or frename() is possible.
17. flink(f,name); links a file descriptor to a name as link(a,b) links two names.
18. frename(f,name); maybe freplace() instead, but replaces name with the contents stored in f the way rename() can be used to atomically replace files.
19. open() flag O_LATER returns a file descriptor now and fails on the first read() or write() if the file couldn't actually be opened.
20. stop screwing up my filesystem! "#!" should search the path, shared libs should search all paths, and software packages NOT WRITTEN BY THE VENDOR should be in/opt/AUTHOR/PACKAGE/VERSION/ or something acceptably similar. use join() to pull in their bins and libs into the main namespace if desired.
I think something that folks are missing here is that Xen is not some whizzbang way to run your favorite Windows programs or to try out new versions (or completely different) of an operating system.
Xen is more similar to VM; it's already great for server farms and when things like OpenSSI become available/usable it'll mean the realization of network-wide clustering that's Tannenbaum's wet dream.
VMware/Qemu/Plex86 might be [aguably] good for those who only pretend to use their computer, but they're absolute piss for Real Work(tm).
... right after airplanes flown by terrorists crash into (say) the parilment building. Then no terrorists will claim responsibility, but all them towlheads will have a good laugh as Microsoft get's the Benny Hill punishments...
Re:Tradeoff between "simple" and "useful"
on
SPF Design Frozen
·
· Score: 1
statements like that, "v=spf1 +mx +ptr +include:rr.com -all" are dangerous- they add extra complexity to the client which is EXACTLY where we don't need complexity- and they're difficult to be correct. How do you know you didn't accidentally type "... +include:. rr.com -all" -- that's as good as nothing, and isn't that easy to spot.
this requires too many levels of parsing and difficulty on the client. it also "tells too much", a better answer involves knowing the IP and the return-path and examining:
1.0.0.10._spf.example.com
for a "valid" record. existing RBL-publishing software can be used, existing RBL-scanning clients can be used, we won't need to set up DNS-over-TCP servers, and we don't give any information we don't have to.
note, and this is very important. what we're looking for is what would better be called a "reverse MX"-- something that describes where mail _comes_from_ so users with separate mail-clusters for outbound and inbound can identify themselves as such.
RR's are dumb anyway...
Advantages: * utilizes DNS compression for what it's worth * no fancy parsing required * no new levels of indirection * no sendmail-style configuration barf * doesn't publish anything special
Disadvantages: * doesn't require thirty pages to describe:)
We, the internet community understand fully that you (verisign) are doing us a favor by maintaining root DNS servers, and that you have a right to reclaim some of that effort and cost by using the ubiquity of that favor to gain corporate value.
Therefore, because we don't want to devalue you as a company, we don't want you to do us a favor anymore. we've got some u-hauls heading to your offices that will pick up the machines and move them to Mr. Longbeard who is perfectly willing to do us the favor that we like, and is really looking forward to making anagrams out of bind zone files.
We hope you enjoy the relief of having to maintain the public service, and look forward to some most excellent crossword puzzles from Mr. Longbeard.
it's hideous to keep hearing about how programmers cannot possibly design good, clean, consistant user interfaces. i have a hard time finding a case where it's a non-engineer that has ever in the history of time designed and developed a consistant and usable interface.
It's safe to say that non-artists have a hard time "drawing" things- but the widgets themselves must be _designed_ by an engineer. usually, the best looking, and best feeling interfaces are those built with constant feedback between artists and engineers.
So I place the precarious difference in what it means to design, versus what it means to draw.
I can't draw a straight line with a ruler, but the software I have built has a user-interface that is generally approachable, but always usable.
Part of the engineers job is to decide where options, already categorized, will go- by deciding what those categories go, and where the user will need to find them. The engineer can usually sit back and "think" as if they have never seen this interface before, and any engineer that will actually say that labelling a button "Func2" just to save space is actually good UI isn't a proper engineer at all.
But while engineers do like consistancy, and while they can appreciate approachabilitiy (though to reiterate: they may need prodding to get it there) their first goal is to make it usable. That means that after the user _already knows_ where every button can be found and what every function is, they actually feel comfortable using it.
This is a scary thing; the rest of the world doesn't seem to think "usability" means this at all. And they don't otherwise have a word for "approachability", and still somehow all three are intermingled with consistancy into one umbrella of user friendlyness.
Many engineers like to solve this problem with configurability- to make it possible to change every behavior of the software (that they think) possible, so that users can find their own usable system.
The problem is that nobody but an aspiring engineer or better can do that.
And if nobody but an engineer can actually define (and therefore design) the usability, and if clearly usability is paramount in a programs, well, use, then it should not only be obvious and apparent, but you will grin widely when you notice that not only are engineers the best user-interface designers, they are the only people who can make it work.
Apple computer is often cited as an example of consistancy (well, except for their cross-platform offerings) but do you honestly think it was the artist that did anything but decide what a slider should _look like_? Not that a slider was the best tool, or that "some kind" of gauge was necessary, but find an artist that does this, and I'll start calling them an engineer.
Well, not now anyway... Almost everyone has seen a slider, so let's change that above examine to be a quokulfork. Non-engineers, your challenge is to decide what the quokulfork is, and since you can already draw it, do that, and decide how it works, and why it's necessary.
I mean, the quokulfork: the most needed UI element.
You can't think we've thought of all of them. After all, how did Macintosh go so long without a slider widget?
mtas and print servers have a lot in common- so much so that with a simple "dequeing" program (that serializes message input) you can use your qmail [or other mta] as your printing system.
The obvious benefit is that you get to avoid weird printcaps, and all the different "stages" in which a program decides if it's postscript, native for the printer, resizing paper, etc.
Of course, using an MTA as your print server has other security issues to watch for- fortunately, these issues are for the MTA and mailboxes itself. So you don't have to learn the security details of two queue-action systems- only the one that you'd be using anyway:)
You won't have internet-printing-protocol, or an LPD server [although I suppose it wouldn't be that difficult to hook one into qmail-inject...], fortunately it seems that these things are less-important- at least on our network.
One of our clients uses those cheap print-server boxes, and has a Win2k box that can't seem to understand IPP. No matter, the box can send mail, so everyone's happy (infact- the program actually has a "print to email function" - so while it sounds weird to print to email to a printer, it's actually not that big of a workaround for them)
Anyway, back to CUPS... CUPS is a lot like sendmail. Yes, the configuration file looks slightly less like line noise, but it is complicated enough to warrent an entire [thick] book on the subject. I don't need IPP or foomatic or 10% of my programs to think my printer actually understands A4 paper, OR reading configuration files that make me think someone picked up the phone... I'll just stick to my qmail-printer.
The largest problem with internet mail is that the cost of delivery is on the recipient. Certification paths are always brought up- either by people who don't understand the real issues, or by genuinely dumb people.
The one true solution is to move the cost of delivery onto the sender. The recipient needs to be charged with the task of picking up their mail. If you'd like to look at it using existing technologies, think of everyone having a different POP server for every sender that delivers them mail.
The obvious benefit is that it's simply not possible for the bad guys to deliver you email. But mailing lists get cheaper too, and there becomes no such thing as a bounce-back.
Most people will want to add people manually. A robot confirm system (image or audio related- human readable- not robot readable) that exists on my website would allow you to add your POP server to my POP list.
I've talked about this quite a bit, and the two questions everyone seems to ask is "but that's just like certification" (which isn't a question), and "pop is on the way out. it should be imap instead" (which also isn't a question). The latter is easy- of course it doesn't have to be POP3. IMAP isn't terribly friendly for this application either, but you're right in thinking that it doesn't matter. Mailing lists may want an IMAP-like system, but for single-delivery, you'll probably want something more like POP. You'll download you message once to your system - whether that be your workstation, or a centralized server that can keep all of your mail for you.
Now about certification. I think many people miss some very important details:
I am not a robot. I choose individually to add your POP server to my list. I don't trust who you trust, and I feel free to remove that server at any time.
The mail comes down ALWAYS on my request, or not at all. Never on yours. I get to choose when is the "cheap bandwidth" time for my neighborhood, not you.
Even though you've given me a POP server, does not mean I have to read your email. See above.
Even though you've given me a POP server does not mean I have to read all your email. This one is important. If you're "sending" five-gig messages you only fill up your own hard drive. I don't have to accept the first meg whether I like it or not and then tell you know. I get to know before hand. If I feel like you're lying, I'll never read your mail again.
And finally, the most important detail is that we are moving the cost of delivery from the recipient back to the sender- if you have EVER been in a time or place where your bandwidth was costing you by the minute, then you'll know why this is so important. For those of you that don't; get an imagination.
I keep a work-bag with:
* thinkpad
* various pcmcia goodies
* palm V with usb charge/sync cable
* some funny-make sprint phone with a builtin 14.4k modem (9-pin serial DIN for laptop or palm V)
* rio mp3 player
despite being a pursesnatchers wet-dream, it's got everything i need to administer one of my servers remotely. I like keeping them seperate too:
They all have seperate power sources, so draining one doesn't kill me completely (I have fixed many problems with nothing more than my palm and my phone), in many cases, I can use one's battery to run another for a short while (in a pinch), and the total battery usage is MUCH LOWER than a more integrated solution.
I get about 4-5 hours "talk time" before my cellphone needs it's battery swapped out. With it's built-in 14.4k modem, it's not draining my laptop battery (which can do about the same-- a little bit less under heavy use though) -- and it doesn't take as much power to drive those serial ports as it does to drive a pcmcia cellular modem.
I can charge the palm, modem, and rio all off the USB wire (drawing power from the laptop), and overall, survive the moderately-connected life for about three days total, just with what's in the bag.
Maybe just keeping contacts and telephone numbers memorized is all you guys do with your gadgets, but I actually have work to do...
it truly would be nice to have an AOL client for Linux. But they really only have two options: 1. support ONLY UNMODIFIED RPM-ONLY REDHAT BOXES (or xxx other distribution) 2. build an all-in-wonder static library that has the dialer, gecko, vpn client, and everything all built-in.
no linux user really wants either option, but it does sound off a big reason why companies are reluctant to bring desktop-software to linux: there are too many variables.
There is a good reason that "Reinstall Windows" is in the 90th percentile of all support responses. It's a simple answer, and by having nobody who can actually repair a broken windows machine, it's the best answer.
But linux systems can be repaired so long as they still kick (and sometimes: even past that point). So there's two options for us:
1. we can adopt some kind of sane configuration system. [i think freshmeat had an article about the unix configuration nightmare, so don't expect the answer to this to begin with the word "just"]
2. we can all adopt a single limiting platform for desktop use, and do all our hacking in every other system.
If people really believed point #2 was a possibility, I think we would have a lot more desktop presense already. But #1 has the most promise. If people weren't so angry as to say "configuration like XXX is too YYY" instead of saying "configuration like YYY is unreliable because ZZZ" we might actually key someplace.
And everyone would have to adopt it. Gnome moves somewhat forward with gconf, but don't think it's the end-all. we'd have to have dialup and network configuration, and X configuration and everything in a similar engine. In this case, we can ditch gconf completely, or we can build wrappers to do just this.
i don't play a lot of games (actually, besides GTA3 and dynasty warriors 2 - i don't play any), so it's no suprise that I don't see a lot of reviews.
But what bothers me is that I used to. It seems like game magazines USED to have a ratio like 30% review, 25% featured-item, 20% advertising, 10% news and letters, and maybe 5% for editorials, and 5% for "previews" -- and the previews rarely showed much of the game at all. Normally it was a mention of a particular title being licensed, a sequal game, or something like that.
Those previews were also explicitly labled that- they didn't pass off as an actual game review. And most of the actual game reviews were for games no less than a month old. Maybe the magazines only had previews then, but it seems like they at least passed it off better.
Or maybe it's just that video games weren't as big an industry back then. Or maybe games were finished sooner (distribution costs higher== more time to get out the door)
But something did this. It doesn't suprise me that this happens, but it seems suspiciously creeping: like Mcdonalds cheeseburgers shrinking over the past ten years, or television shows getting shorter.
I can understand the economic ramifications, but surely these must be reduced to advertising - and as such, shouldn't there be an explicit truth-in-advertising?
I don't want my kid comming up to me saying "OOH I WANT THIS GAME" -- I'd like to look at the bottom of the page or something and see a little label like they put on packs of cigarettes that says something like "WARNING: THIS GAME MAY NOT EXIST, AND THE PICTURES ARE FABRICATED" so I can tell the difference between a fun-looking and sounding game, and a fun-looking and sounding advertisement.
Anyway, I guess I'm glad this hit slashdot -- I might not have thought about this otherwise...
Slashdot Mirror
It isn't illegal. It's anticompetitive. What's illegal is for companies to be anticompetitive in markets that they have monopolies.
... and one more:
5. maybe browsers should just display nonlocal scripts in a different, hilighted color (or different background color)....
0. someone should've been paying attention when Verisign- the self-proclaimed "leeders" in Internet security- signed a code-signing certificate for Microsoft.... for someone who wasn't Microsoft.
1. people shouldn't be entering credit card or login information into a page that they clicked on from an email.
2. unicode should've been arranged by glyph similarity instead of by script family.
3. people shouldn't cry about having a domain name "in their script." - domain names are _supposed_ to be easy to type, and easy to remember. IDNs are neither to people foreign to that script, and often, neither to people even USING that script.
4. people should've been less afraid of bookmarks.
I understand this behavior because I see it; Our very own Fearless Leader exhibits this "thin slicing" with a remarkable success rate.
I do a significant amount of research in an effort to predict certain kinds of market trends and behaviors but what bothers me is that he [often] gets the same results without that work.
Nevertheless, I wonder mostly, why he is dismissive of a technical method that produces his results. Sometimes, it produces different results, and for those times he is extremely grateful, but when it doesn't- that is, when a technical and exhaustive method yields the same result as his snap decisions, he is very frustrated that the technical method was performed at all.
Like it's "obvious" to those of us without the manager hair and posture...
Consider getting a cordless presentation mouse. The kind that doesn't need a surface and either rocks, or has a knob on it for use. You can get 'em at staples for pretty cheap and they do work.
I prefer the Thinkpad nipple, and abhor the touchpad -and-go-the-opposite-way. The presentation mice work as a weak substitute.
Whoever you look at, call their support desk try reciting scenarios described in BOFH articles. Pick something obscene. Tell them you have put seeds and jam in your cdrom tray and need to get your website back up.
You'll know you found a good place when the support desk has actually been there.
10$/month hosting companies simply haven't. Even most 20$/month companies don't.
They have an answering service that takes a message. They'll probably email you later if they bother helping at all. They'll probably ignore you because jam and seeds aren't that funny.
In fact, there are very few 20$/month hosting companies that even have a hand in their own servers. Be wary of a company that can't support themselves.
Chances are, they can't support you either.
LARGE businesses CAN do the cost analysis. They CAN think 30 years in the future. They CAN see that increasing everyones' typing rate 5wpm over the course of 30 years DOES make them money.
The problem is that changing keyboards does NOT increase typing rate EVEN 5wpm (across the board), and it doesn't translate into greater productivity.
If someone DOES come up with a keyboard that is guaranteed to make an old fart like me type faster with less hand/wrist pain when acclimated - there is no doubt that the world will switch.
So to keyboard inventors everywhere: If you come up with a great idea, and it doesn't seem to be catching on: Don't do what DVORAK did and invent a whole bunch of "studies" that can't be reproduced.
Instead, go try and invent another keyboard layout. You might be on to something with the first one, but it obviously isn't right (yet).
_I_ use QWERTY to avoid hand/wrist pains.
I am a capable DVORAK typist (0%err.approx. 45-55 wpm), and an excellent QWERTY typist (0%err.approx. 80-95 wpm).
I also suffer from incredible wrist and forearm pains from typing too long (or too fast).
Other hackers should be able to attest to this: under a good hacking session, that "0% error approximate" typing rate can go up quite a bit. I've had bursts of 5-12 minutes of well over 120wpm, with zero error.
I try and minimize those moments (when I notice they are happening) because it usually means my forearms are about to swell up and my wrists are about to stop responding without severe pains.
At first, when I was learning DVORAK I never had any pains- but I assumed this was because of the low typing speed, and in a way, I was right.
As I started picking up speed (and entering hack-mode in DVORAK), I noticed the pains coming. But even while barely reaching 45wpm in DVORAK, it was still hurting in about the same amount of time as my 85wpm QWERTY.
You see, when typing DVORAK, my hands certainly don't do much travelling, but I end up with enormous bias- using my left hand for several characters in a row, then getting a single right-hand key, before going back to the left hand. This lack of hand-travel definately contributed to learning how to type DVORAK very quickly.
When using QWERTY, on the other hand, my hands do MORE travelling (more still because of vi's escape-key fetish) but I find I'm using both hands more evenly. I've noticed that hand travel (however) doesn't stop my typing; i.e. my left hand will travel while my right is still typing.
Some say I can improve my DVORAK speed, and surely I know many folks that say their highest DVORAK speed is higher than their highest QWERTY speed. I also know of many more who haven't found any discernable difference in "top speed".
But note that I'm deliberately keeping my QWERTY speed down, as going MUCH too fast accelerates the pains.
Since DVORAK "hurts" at 50wpm where QWERTY "hurts" at 90wpm, I think it's easy to see why I use QWERTY to avoid hand/wrist pains.
of course they have a sense of humor. don't you see the full-page jokes they publish in IT journals?
"In many cases the response is we need to stick with the version that's available at the time that we purchased that distribution, so for example if I'm running Apache 1.3 on my Red Hat Enterprise server, although I may want Apache 2.0 because it might have new features or it might have some new capabilities, I'm outside of my support model now with Red Hat."
Is this a bad thing? Does Microsoft do something different? Can I get IIS6 supported on Windows 2000? Can I get Apache2 supported on Windows 2000?
"... if you take a look at Intertrust, the company that filed suit against Microsoft for patent infringement, Microsoft wrote a check for $440 million and our customers did not have to do anything in their implementation of Microsoft technology nor feel the pain, let's just say, of that situation."
If I used Microsoft software (That's a pretty big IF), would anything be different for me if Microsoft DIDN'T pay off Intertrust? Does Microsoft really think that if I don't violate a patent, I can be sued because they did?
"Obviously, Microsoft is incredibly focused on security."
Right... Obviously...
1. select()ing files actually demands that read() not block.
/opt/AUTHOR/PACKAGE/VERSION/ or something acceptably similar. use join() to pull in their bins and libs into the main namespace if desired.
2. shadowlink() which allows for rename()ing the original to atomically update the shadow()
3. rename()ing a file into a directory that's opened has it's entry added to the end of the readdir() queue for that other process IF the original name hasn't been seen in that directory [yet]
4. join(a,b) syscall which attaches directory b's contents into directory a for this process and all children. a complementary unjoin(a) and unjoin2(a,b) which remove all joins, and a specific join respectively.
5. fork() return a file descriptor. writing to the file descriptor sends that signal. reading from the descriptor wait()s for it's status. close()ing the file descriptor detaches. if you really wanted to, getfpid(f) returns the opaque pid of the peer on f. getpfid(p) does the reverse. getpfid(-1) or 0 returns the file descriptor for the current process.
6. splitsocket(s,&i,&o) returns a pair of ofiles. reading from i is the same as reading from s. writing to o is the same as writing to s. closing i is the same as shutdown(SHUT_RD); closing o is the same as shutdown(SHUT_WR); closing(s) after splitsocket() does nothing.
7. poll2() which uses struct poll2s which are a linked list and have a void*userv; for user data.
8. disablenetwork() which kills the current process and any child processes ability to use routable network traffic.
9. bootnumber() and poweronseq() which return the number of boots this system has had and the number of times poweronseq() has been called by any process. these together can be used for sequence number generation.
10. daemons are stupid. let the shell background them.
11. seek() on a pipe will generate a SIGPIPESEEK on the peer if the peer handles it (default/ignore is to generate the normal error with no side effects). that signal has in its sigaction the desired offset.
12. postfd(f) returns a 1024-byte random token that another process can use getfd(tok) to get that fd without using any other communication channel.
13. mapf(addr,len) creates a file descriptor from the current process address space. mmap()ing that fd can reobtain that address space - even after exec().
14. insist csh be never again used for programming.
15. audit(f); system call which raises SIGSTOP for this process (and all children) whenever they do an operation that touches f. if f is a directory, then this includes all children of f, ignoring symlinks. a debugger can notice this.
16. anonf(x) returns a file descriptor that is backed by some inaccessible file space without a name. if x is >-1 then it will be on the same filesystem as "x" is, and thus flink() or frename() is possible.
17. flink(f,name); links a file descriptor to a name as link(a,b) links two names.
18. frename(f,name); maybe freplace() instead, but replaces name with the contents stored in f the way rename() can be used to atomically replace files.
19. open() flag O_LATER returns a file descriptor now and fails on the first read() or write() if the file couldn't actually be opened.
20. stop screwing up my filesystem! "#!" should search the path, shared libs should search all paths, and software packages NOT WRITTEN BY THE VENDOR should be in
the problem is that when there's 1 little error in ASP.net the entire server is rooted.
I think something that folks are missing here is that Xen is not some whizzbang way to run your favorite Windows programs or to try out new versions (or completely different) of an operating system.
Xen is more similar to VM; it's already great for server farms and when things like OpenSSI become available/usable it'll mean the realization of network-wide clustering that's Tannenbaum's wet dream.
VMware/Qemu/Plex86 might be [aguably] good for those who only pretend to use their computer, but they're absolute piss for Real Work(tm).
... right after airplanes flown by terrorists crash into (say) the parilment building. Then no terrorists will claim responsibility, but all them towlheads will have a good laugh as Microsoft get's the Benny Hill punishments...
statements like that, "v=spf1 +mx +ptr +include:rr.com -all" are dangerous- they add extra complexity to the client which is EXACTLY where we don't need complexity- and they're difficult to be correct. How do you know you didn't accidentally type "... +include:. rr.com -all" -- that's as good as nothing, and isn't that easy to spot.
this requires too many levels of parsing and difficulty on the client. it also "tells too much", a better answer involves knowing the IP and the return-path and examining:
:)
1.0.0.10._spf.example.com
for a "valid" record. existing RBL-publishing software can be used, existing RBL-scanning clients can be used, we won't need to set up DNS-over-TCP servers, and we don't give any information we don't have to.
note, and this is very important. what we're looking for is what would better be called a "reverse MX"-- something that describes where mail _comes_from_ so users with separate mail-clusters for outbound and inbound can identify themselves
as such.
RR's are dumb anyway...
Advantages:
* utilizes DNS compression for what it's worth
* no fancy parsing required
* no new levels of indirection
* no sendmail-style configuration barf
* doesn't publish anything special
Disadvantages:
* doesn't require thirty pages to describe
We, the internet community understand fully that you (verisign) are doing us a favor by maintaining root DNS servers, and that you have a right to reclaim some of that effort and cost by using the ubiquity of that favor to gain corporate value.
Therefore, because we don't want to devalue you as a company, we don't want you to do us a favor anymore. we've got some u-hauls heading to your offices that will pick up the machines and move them to Mr. Longbeard who is perfectly willing to do us the favor that we like, and is really looking forward to making anagrams out of bind zone files.
We hope you enjoy the relief of having to maintain the public service, and look forward to some most excellent crossword puzzles from Mr. Longbeard.
it's hideous to keep hearing about how programmers cannot possibly design good, clean, consistant user interfaces. i have a hard time finding a case where it's a non-engineer that has ever in the history of time designed and developed a consistant and usable interface.
It's safe to say that non-artists have a hard time "drawing" things- but the widgets themselves must be _designed_ by an engineer. usually, the best looking, and best feeling interfaces are those built with constant feedback between artists and engineers.
So I place the precarious difference in what it means to design, versus what it means to draw.
I can't draw a straight line with a ruler, but the software I have built has a user-interface that is generally approachable, but always usable.
Part of the engineers job is to decide where options, already categorized, will go- by deciding what those categories go, and where the user will need to find them. The engineer can usually sit back and "think" as if they have never seen this interface before, and any engineer that will actually say that labelling a button "Func2" just to save space is actually good UI isn't a proper engineer at all.
But while engineers do like consistancy, and while they can appreciate approachabilitiy (though to reiterate: they may need prodding to get it there) their first goal is to make it usable. That means that after the user _already knows_ where every button can be found and what every function is, they actually feel comfortable using it.
This is a scary thing; the rest of the world doesn't seem to think "usability" means this at all. And they don't otherwise have a word for "approachability", and still somehow all three are intermingled with consistancy into one umbrella of user friendlyness.
Many engineers like to solve this problem with configurability- to make it possible to change every behavior of the software (that they think) possible, so that users can find their own usable system.
The problem is that nobody but an aspiring engineer or better can do that.
And if nobody but an engineer can actually define (and therefore design) the usability, and if clearly usability is paramount in a programs, well, use, then it should not only be obvious and apparent, but you will grin widely when you notice that not only are engineers the best user-interface designers, they are the only people who can make it work.
Apple computer is often cited as an example of consistancy (well, except for their cross-platform offerings) but do you honestly think it was the artist that did anything but decide what a slider should _look like_? Not that a slider was the best tool, or that "some kind" of gauge was necessary, but find an artist that does this, and I'll start calling them an engineer.
Well, not now anyway... Almost everyone has seen a slider, so let's change that above examine to be a quokulfork. Non-engineers, your challenge is to decide what the quokulfork is, and since you can already draw it, do that, and decide how it works, and why it's necessary.
I mean, the quokulfork: the most needed UI element.
You can't think we've thought of all of them. After all, how did Macintosh go so long without a slider widget?
mtas and print servers have a lot in common- so much so that with a simple "dequeing" program (that serializes message input) you can use your qmail [or other mta] as your printing system.
:)
The obvious benefit is that you get to avoid weird printcaps, and all the different "stages" in which a program decides if it's postscript, native for the printer, resizing paper, etc.
Of course, using an MTA as your print server has other security issues to watch for- fortunately, these issues are for the MTA and mailboxes itself. So you don't have to learn the security details of two queue-action systems- only the one that you'd be using anyway
You won't have internet-printing-protocol, or an LPD server [although I suppose it wouldn't be that difficult to hook one into qmail-inject...], fortunately it seems that these things are less-important- at least on our network.
One of our clients uses those cheap print-server boxes, and has a Win2k box that can't seem to understand IPP. No matter, the box can send mail, so everyone's happy (infact- the program actually has a "print to email function" - so while it sounds weird to print to email to a printer, it's actually not that big of a workaround for them)
Anyway, back to CUPS... CUPS is a lot like sendmail. Yes, the configuration file looks slightly less like line noise, but it is complicated enough to warrent an entire [thick] book on the subject. I don't need IPP or foomatic or 10% of my programs to think my printer actually understands A4 paper, OR reading configuration files that make me think someone picked up the phone... I'll just stick to my qmail-printer.
The one true solution is to move the cost of delivery onto the sender. The recipient needs to be charged with the task of picking up their mail. If you'd like to look at it using existing technologies, think of everyone having a different POP server for every sender that delivers them mail.
The obvious benefit is that it's simply not possible for the bad guys to deliver you email. But mailing lists get cheaper too, and there becomes no such thing as a bounce-back.
Most people will want to add people manually. A robot confirm system (image or audio related- human readable- not robot readable) that exists on my website would allow you to add your POP server to my POP list.
I've talked about this quite a bit, and the two questions everyone seems to ask is "but that's just like certification" (which isn't a question), and "pop is on the way out. it should be imap instead" (which also isn't a question). The latter is easy- of course it doesn't have to be POP3. IMAP isn't terribly friendly for this application either, but you're right in thinking that it doesn't matter. Mailing lists may want an IMAP-like system, but for single-delivery, you'll probably want something more like POP. You'll download you message once to your system - whether that be your workstation, or a centralized server that can keep all of your mail for you.
Now about certification. I think many people miss some very important details:
And finally, the most important detail is that we are moving the cost of delivery from the recipient back to the sender- if you have EVER been in a time or place where your bandwidth was costing you by the minute, then you'll know why this is so important. For those of you that don't; get an imagination.
just remember to # touch /yourself before the 15th of every month and you'll be okay...
I keep a work-bag with:
* thinkpad
* various pcmcia goodies
* palm V with usb charge/sync cable
* some funny-make sprint phone with a builtin 14.4k modem (9-pin serial DIN for laptop or palm V)
* rio mp3 player
despite being a pursesnatchers wet-dream, it's got everything i need to administer one of my servers remotely. I like keeping them seperate too:
They all have seperate power sources, so draining one doesn't kill me completely (I have fixed many problems with nothing more than my palm and my phone), in many cases, I can use one's battery to run another for a short while (in a pinch), and the total battery usage is MUCH LOWER than a more integrated solution.
I get about 4-5 hours "talk time" before my cellphone needs it's battery swapped out. With it's built-in 14.4k modem, it's not draining my laptop battery (which can do about the same-- a little bit less under heavy use though) -- and it doesn't take as much power to drive those serial ports as it does to drive a pcmcia cellular modem.
I can charge the palm, modem, and rio all off the USB wire (drawing power from the laptop), and overall, survive the moderately-connected life for about three days total, just with what's in the bag.
Maybe just keeping contacts and telephone numbers memorized is all you guys do with your gadgets, but I actually have work to do...
it truly would be nice to have an AOL client for Linux. But they really only have two options:
1. support ONLY UNMODIFIED RPM-ONLY REDHAT BOXES (or xxx other distribution)
2. build an all-in-wonder static library that has the dialer, gecko, vpn client, and everything all built-in.
no linux user really wants either option, but it does sound off a big reason why companies are reluctant to bring desktop-software to linux: there are too many variables.
There is a good reason that "Reinstall Windows" is in the 90th percentile of all support responses. It's a simple answer, and by having nobody who can actually repair a broken windows machine, it's the best answer.
But linux systems can be repaired so long as they still kick (and sometimes: even past that point). So there's two options for us:
1. we can adopt some kind of sane configuration system. [i think freshmeat had an article about the unix configuration nightmare, so don't expect the answer to this to begin with the word "just"]
2. we can all adopt a single limiting platform for desktop use, and do all our hacking in every other system.
If people really believed point #2 was a possibility, I think we would have a lot more desktop presense already. But #1 has the most promise. If people weren't so angry as to say "configuration like XXX is too YYY" instead of saying "configuration like YYY is unreliable because ZZZ" we might actually key someplace.
And everyone would have to adopt it. Gnome moves somewhat forward with gconf, but don't think it's the end-all. we'd have to have dialup and network configuration, and X configuration and everything in a similar engine. In this case, we can ditch gconf completely, or we can build wrappers to do just this.
i don't play a lot of games (actually, besides GTA3 and dynasty warriors 2 - i don't play any), so it's no suprise that I don't see a lot of reviews.
But what bothers me is that I used to. It seems like game magazines USED to have a ratio like 30% review, 25% featured-item, 20% advertising, 10% news and letters, and maybe 5% for editorials, and 5% for "previews" -- and the previews rarely showed much of the game at all. Normally it was a mention of a particular title being licensed, a sequal game, or something like that.
Those previews were also explicitly labled that- they didn't pass off as an actual game review. And most of the actual game reviews were for games no less than a month old. Maybe the magazines only had previews then, but it seems like they at least passed it off better.
Or maybe it's just that video games weren't as big an industry back then. Or maybe games were finished sooner (distribution costs higher== more time to get out the door)
But something did this. It doesn't suprise me that this happens, but it seems suspiciously creeping: like Mcdonalds cheeseburgers shrinking over the past ten years, or television shows getting shorter.
I can understand the economic ramifications, but surely these must be reduced to advertising - and as such, shouldn't there be an explicit truth-in-advertising?
I don't want my kid comming up to me saying "OOH I WANT THIS GAME" -- I'd like to look at the bottom of the page or something and see a little label like they put on packs of cigarettes that says something like "WARNING: THIS GAME MAY NOT EXIST, AND THE PICTURES ARE FABRICATED" so I can tell the difference between a fun-looking and sounding game, and a fun-looking and sounding advertisement.
Anyway, I guess I'm glad this hit slashdot -- I might not have thought about this otherwise...
it appears to have been posted to the wrong topic.
it should've gone to the NZ ethernet.