I've been getting into Ruby on Rails recently, and am most excited by how Rails makes it very clear what the "best practices" for organizing and building your application is.
I have long despaired of learning that same information for PHP (with which I have much more experience). I've not yet found a book or other documentation that provides a concrete approach. And looking at existing large-scale projects, e.g., WordPress and others, reveal a myriad of different philosophies. It leaves developers basically trying different things out on different projects, and picking up their own favorite best practices as they go along.
While it's great that the languages are so flexible, well, sometimes it's nice to be guided to a known solid approach. It leads to consistency among and across many developers and time. This makes it easier for new developers to join or take over a project, or even for the original developer to do maintenance on components which were written long ago.
So, where are the recommended approaches for organizing and constructing large-scale applications for PHP (and Python, etc.)?
>No-one seems to understand that a distro might be chosen >for certain reasons and that changing is not an option, things >have to be made made to work.
I hear your point, but I think you are missing another one. What the parent was trying to say, I think, is that the technology exists in the open source community to do what you need to do. The fact that Distro X didn't pick up the technology and package it isn't the OSS community's fault - it's the distro packager's fault. So in other words, don't be so quick to judge the entire OSS community based on what specific people or companies have done (or said).
No, actually, you are still missing the point. The point being, the Open Source process is highly decentralized. This has many advantages -- no one disputes that in the two articles being discussed here.
But it also has several disadvantages. One of them is the chaos of multiple distributions. Another is terrible UI design. Neither of these serve users well, unless by "users" you are limiting the population down to the folks who actually care about the differences between Linux distributions.
Most of us don't. We want to get a Linux that works, and be done. We want to open our printer config panel, have it work, and be done. We don't want to think about, well, this distro has this, but that distro has that, so which one should I get?
Combines well with Bayesian filtering
on
SPF Design Frozen
·
· Score: 1
A lot of folks have commented that this won't do anything to reduce spam, because spammers will just register new domains and send from those.
But, those new domains won't have any data in people's Bayesian corpus; they will be neutral in affecting spam probability scores.
On the other hand, domains that publish SPF records will be protecting their domain names, which means that those domain name tokens in people's Bayesian corpuses will count positively towards the message not being spam.
In other words, publishing SPF records for your domain can keep your domain from becoming a spam keyword in Bayesian filtering. I think this will likely improve the effectiveness of Bayesian filters overall.
SPF isn't a silver bullet -- and does not claim to be -- but every little bit helps.
Re:Print to PDF from Mac is inefficient
on
OpenOffice.org Hits 1.1
·
· Score: 5, Interesting
I love the capability of Mac OS X to print anything to a PDF file, it's a great feature to use in a pinch. But it's no substitute for a real PDF generation tool, like Acrobat, or functionality built into OpenOffice.
The file size different noted here (22MB vs 2.3MB) is hardly unusual; indeed, it's the rule, not the exception. In dozens of attempts, I never made a PDF file remotely close to what Acrobat Distiller was capable of doing, size-wise.
If your job doesn't depend on being able to send people PDF files, the built-in version is fine. But if you share your PDFs regularly, spend the time or the bucks to get a real PDF solution.
I can personally recommend Java Software Solutions: Foundations of Program Design, by Lewis & Loftus. We used this textbook (the first edition, link above is the 3rd edition) in an introductory programming class, and it's very focused on program design first, Java second.
I will say, however, that a big part of what made the text successful in our class was the outstanding instructor, who gave a programming assignment every week, of his own design, rather than those from the book. Then again, I loaned my non-technical boss the book, to supplement her readings for the Java class she was taking, and she found it much more helpful than the text assigned by the instructor. In fact, she still hasn't returned it...
Another possibility would be Objects First with Java: A Practical Introduction Using BlueJ. BlueJ is an IDE specifically designed for the teaching of object-oriented programming, using Java. If you go to the BlueJ web site, you can learn more about the IDE (which is freely downloadable) and the pedagogical philosophies behind it.
I should say, I have not had personal experience with this text, just that it sounds like it might fit your requirements fairly well.
As blacklists go, SPEWS is the worst of them. They block entire netblocks so that innocent bystanders will fight their fight for them. If my IP gets blocked even though I haven't sent any SPAM, I am expected to bitch to my ISP and/or move to another ISP, and then maybe in a couple of months my IP might get removed from the list.
You don't understand SPEWS, or the word "innocent." If you are a customer of a spammer-friendly ISP (which is the only way SPEWS can hurt you), then you are a part of the problem, a silent collaborator with the spammers.
Patronizing spammer-friendly ISPs is almost as bad as actually buying things from spam. You're providing economic incentives to the people who make spam worth their while.
To be perfectly clear: if you're a customer of a spam-friendly ISP, you are supporting spam, and you deserve to be hit by SPEWS.
Yes, OmniWeb 4.5 is a major improvement in terms of quality of rendering and compatibility with more sites. And, as suggested, OmniGroup has indeed implemented features in their browser which would probably be impossible if they only used WebKit. This is a trivial one, but they automatically render hanging punctuation, rather than inline.
Go to http://www.happycog.com/lectures/dwws/ in both OmniWeb and Safari, and look at the placement of the opening quotation mark for the body copy to see this.
Minor feature only typographers will likely notice, but I'm sure there are many more instances where OmniGroup has added "fit-and-finish" to the raw materials provided by Apple.
If a company would come out with a cheap mini-pc just like the one in this article(no fans, small, etc) with 3 or 4 interfaces, I bet they would sell like hotcakes for use as cheap linux firewalls that don't take up a huge amount of space and don't sound like a jet engine all the time.
Soekris Engineering already has these. They build custom single-board PCs which are low-power and run fanless. They are not going to replace a PC for desktop use, but are terrific for firewalls, VPNs, wireless base stations, and the like.
They have several different models, with 2 or 3 network interfaces. The units with 2 interfaces have a slot to take a wireless PCCard to become a base station. They boot off compact flash, or tiny IDE drives. They can take a crypto hardware acceleration card. They can be powered by PoE (Power Over Ethernet).
The new net4801 takes the processor clock up to 233MHz. Like I said, not a speed demon, but it's a beautifully designed piece of hardware.
There's also a nice turnkey firewall package for the Soekris boxes, called m0n0wall, that's pretty functional and virtually idiot-proof. You could build a business selling these things, it's commercial quality polish.
Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front?
You might find Dominic Giampaolo's book about implementing the BeOS File System (BeFS) interesting:
I think Nielsen's wrong here. I find that, for certain types of searches, I want to look at the ads. No, really! Here's an example. My wife and I have one of those WhirleyPop stovetop popcorn popping gizmos. It works reasonably well with regular popcorn and oil, but it's really, really spectacular if you get the pre-measured packets of popcorn, oil, and seasonings.
Right before last Thanksgiving, I went to Amazon.com and searched for WhirleyPop. I could buy more poppers, but not more supplies. So I went to Google. Google's search results (for "popcorn & WhirleyPop") were OK, but the ads were exactly what I was looking for -- vendors who could sell me something, fairly specialized, that's never available in any store I visit.
In this case, it was the ads, not the search results, that were interesting. All of those people were ready to sell me exactly what I wanted. Sometimes, ads are not ads, they are the results themselves.
It says something about our crappy legal system that total crap like this can even be introduced into a court. There should be a pre-trial hearing to determine if something's even worthy of appearing in a court. No fancy legal bullshit, just some guy who looks at something and says, "that's fucking bullshit...trash can". Like the McD's coffee lawsuite, this is fucking bullshit and should have been trashed by the court clerks upon receiving it.
You obviously don't know the facts in the McDonald's coffee lawsuit. McDonald's was serving their coffee -- systematically, as part of the franchise way of doing things -- 30 degrees F higher than "hot", i.e., 180 degrees F instead of 150 F.
Metaphorically, it's a little like the difference between sending someone home with a gun that's not loaded and the safety on, vs. loaded, cocked, and safety off. One is dangerous, but well understood to be so, the other is unnecessarily, negligently dangerous.
Beyond that, McDonald's had a long history of complaints and actions regarding the overly hot coffee. In other words, they were not doing something dangerous unknowingly, they were doing it deliberately.
Regular coffee from your average coffee place will burn you if you spill it on yourself, but it's only a 2nd degree burn. The woman who spilled the coffee on herself suffered 3rd degree burns. Look the difference up in a medical dictionary, preferrably one with pictures, and then imagine yourself having it done to your privates, like she did.
Wonder if you'd think it was a frivolous lawsuit then.
Here's an annecdote. Earlier this year, I was building two new computers from components, for a new server and a desktop Linux system. I initially set out to make low-power, totally silent systems, based around the VIA C3 CPU.
But after doing research into cooling solutions, etc., I decided I could stand a tiny bit of noise, in exchange for greater processing power (I want to run Java web sites off the server box). So I upgraded the CPU to a Pentium III. This was possible, not just because the processors are opcode compatible, but because they were both Socket 370 compatible. Just swapped them out.
I would not have purchased an Intel CPU for the server system if I had made a commitment to a different socket format. So Intel would have lost.
More importantly, as a consumer, I won big time, by having a far more flexible system, that let me make an initial investment based on one set of requirements, and then upgrade the box later, when my requirements changed.
It's a shame that Intel doesn't want to keep this. After all, the C3 processor doesn't really compete with Intel's products -- there's quite a difference in processing power, at similar clock speeds. So let VIA have the low-power low end for us SilentPC enthusiasts, and own the rest. It's basic market segmentation, and Intel knows how to do that, profitably, very well.
I'd really like to see a simple plug-in that adds only one visible element to the standard interface, a smiley/frownie face, ala iCab, that indicates whether the HTML of the page actually validates to the DTD declared in the document itself. Clicking on a frownie face would bring up a list of validation errors. This would be a great tool for site developers, making mistakes quickly visible.
It would be an even better tool for standards evangelism if it was included in the default installation of Mozilla/Phoenix. Then you'd turn the entire population of Mozilla users into nitpickers, who would hound site developers about lack of standards compliance.
From personal experience, nothing makes you fix problems faster than users regularly sending you e-mail about things that are broken. So making it obvious when things are broken would lead to more feedback, and more feedback would lead to more standards-compliant websites.
Which would be good for Mozilla, and all other browser developers who work towards standards-compliance.
One of the things that's always struck me about X is that the type rendering is poor, compared to the state-of-the-art rendering on contemporary commercial OSes. This has been true, in my personal comparisons, over many years. (I.e., as X advances, so does the state-of-the-art, making relative progress nil.)
I remember when I worked at Be, we licensed a renderer from Bitstream, specifically because writing a really good type renderer is exceptionally hard.
Perhaps this is an area where Open Source nees a leg up from a well-funded commercial outfit, like Sun. Can anyone comment on the actual quality of this new library, relative to existing solutions?
What the fuck is wrong with these people? Why can't these developers just work on the fucking project and improve it and make it better without having to rewrite into yet another application? I had the exact same feeling when I saw the Phoenix announcement: WHY?!
I think you've missed the point of the Phoenix project. Have you actually used Phoenix? The browser UI is wonderful -- and that's impossible to achieve in the Mozilla project, because it has to be all things to all people.
Try taking the Is Phoenix Right For You quiz; if you like Mozilla better, great. If you don't, great.
Either way, stop complaining about what other people choose to do with their time.
I have a T68i that I use on the AT&T Wireless GSM network in the Bay Area.
For the most part, I get fine signal strength in all the places that I spend time at, and the phone works great...except at home. My neighborhood (Lower Haight in SF) has terrible coverage, and the phone is unusable.
That said, I was using a Nokia 8860 on AT&T's regular digital network, prior to the T68i, and it was only marginally better at home, and marginally worse elsewhere.
I think the T68i doesn't handle very low signal strength situations very well, but anything above that works fine for me.
While I'm certainly not a fan of the DMCA, I'm not sure this is a poor decision by the courts, etc. I think that it's probably reasonable for Lexmark to be able to forbid third-parties from selling supplies, if that's a business decision they want to make.
However, I don't think that, even if they ultimately win this case all the way up the line, that this is a winning business strategy. I certainly am not going to buy a printer that is tied exclusively to the manufacturer.
This can't be good publicity for Lexmark; every story is explaining that the manufacturer's supplies are more expensive. That's got to have consumers thinking about buying from HP, or Epson, or whomever.
I think this is a classic case of shooting yourself in the foot, and then sueing for the privilege of doing so again.
Can I hear from anyone who uses BBEdit -- what does it hvae that makes it so amazing?
I have been using (and paying for) BBEdit since version 3.something. It is the one piece of Mac OS software for which I order the upgrade first, and look at the new features second. It is one of my favorite pieces of software of all time. I've paid far more than $179 for my copies and upgrades, and consider it money well spent.
If you are a happy vi[m] or emacs user, don't bother to check BBEdit out. You won't like it, for the same reason that, while I can get around, I hate using vi (and never touch emacs). It's a different philosophy of application design.
BBEdit is a Mac OS application first. It conforms to all of the usual HI guidelines, but goes beyond that to provide an extremely well-designed, high-efficiency interface -- for Mac OS users. (vi folks will no doubt compare keystrokes to do the same task; apples to oranges, Mac OS folks don't want to have separate modes for commands vs. input. It goes back to the application philosophy.)
In spite of being Mac OS first, it provides nearly all of the tools and features you'd want in a text editor. Text munging, search-and-replace, grep manipulation, selection of columns, HTML-specific commands, glossaries, syntax highlighting, etc. I've yet to find its equal in a GUI-oriented application. (My favorite on Windows is TextPad, but it's a distant second.)
If you're a vi man, skip BBEdit. But if you're a Mac OS person, or aspiring to be so, you should give it a whirl.
When I bought BBEdit for OS X from the Apple Store last summer, it was $89. It seems to me that the story here is not that they are splitting their product. It already was split. BBEdit was $89, and BBEdit Lite was free. Now it appears they have released a $49 app to replace the free one, and nearly doubled the price of the full version.
Are you sure you weren't paying for an upgrade, or a competitive sidegrade, or some other special introductory offer? BBEdit has been its current price for a while...and worth every penny, IMHO.
Actually, you're confusing the journaling part with the metadata part. A journaling file system only cares about the file system data -- what file fragments are where on the disk. Nothing else.
The metadata that John Siracusa is asking for is actually very different. He's interested in seeing additional attributes added for files -- things like the file's MIME type, preferred handler, etc.
Be's BFS had all of these things, but not just as part of the journal. There was a lot more to BFS than just the journaling part!
This article contains a number of inaccuracies and omissions, which leads one to wonder if the author is not writing with rose-colored glasses firmly in place:
1. "BeOS is fully POSIX compliant" -- not correct; it would be more accurate to say "mostly" rather than fully. I could quote from the Be FAQs on this point, because I wrote the original FAQ (I worked at Be for three years).
2. USB & FireWire support -- the article states that the USB support is not very complete, and shortly thereafter implies that FireWire is supported more fully. It's really more the reverse, though I doubt if the USB code would work with much of the built-in USB hardware being released these days (you never know, though; we got the original stack from Intel). At any rate, if you happen to have a BeOS retail box, you'll see USB listed (along with the Intel credit), and no FireWire (though my most current box is for R4.5, not R5).
3. Design of the kernel -- I can't comment on a technical level, but my recollection of conversations with kernel engineers was more that the kernel was monolithic (and that we thought that was a good thing). The design inspiration was from the XINU operating system ("XINU" is "UNIX" backwards), I'll leave it to operating systems connoisseurs to determine whether that compares with the Hurd or L4, as the author asserts. Perhaps the author is thinking of a new kernel being written for the "not dead yet" OpenBeOS project(s).
In all, the article reminds me altogether too much of the many articles about the Amiga OS that I read while I worked at Be. Sad, but true. I wish those projects luck -- I miss Be and BeOS -- but I consider them wishful thinking. I've moved on to Mac OS X, and don't plan to go back.
Maybe the team now at Palm will change my mind -- I hope so!
A year and a half ago, my dot.bomb went under, and they gave us a pretty egregious agreement to sign. I signed it and turned it in, because I had not only severance (really, paying out of my vacation) but also several thousand dollars in expenses (training classes I'd put on my credit card).
However, upon further research and advice from others who had done this before, it turned out that I could have instead filed with the California Labor Board, and gotten not only the severance and expenses, but penalties if they were not paid in a timely fashion.
So, if I'd done some research, and been willing to go without the checks for a few extra weeks (or maybe a few months), I might have actually made more money not signing the agreement
In the end, though, the one-sided terms made the agreement a null contract; I was getting nothing (that I was not already entitled to by law), the company was getting something, and a valid contract requires that both parties actually get something from the other. I don't feel bound by the agreement (in areas like confidentiality, not talking trash, etc. -- though I don't have any reason to violate them either), and don't have any reason to test the more expensive clauses (not suing).
The real point here is, if you don't want to sign for some reason, look into your local labor laws. In California, the process for filing is (apparently) fairly simple, and the process of finding against the company is straightforward.
There are usually local organizations, usually not-for-profits, which can advise you of your rights and the law. Look for them via Google, if you can't find someone to give you a direct reference.
Slashdot Mirror
I've been getting into Ruby on Rails recently, and am most excited by how Rails makes it very clear what the "best practices" for organizing and building your application is.
I have long despaired of learning that same information for PHP (with which I have much more experience). I've not yet found a book or other documentation that provides a concrete approach. And looking at existing large-scale projects, e.g., WordPress and others, reveal a myriad of different philosophies. It leaves developers basically trying different things out on different projects, and picking up their own favorite best practices as they go along.
While it's great that the languages are so flexible, well, sometimes it's nice to be guided to a known solid approach. It leads to consistency among and across many developers and time. This makes it easier for new developers to join or take over a project, or even for the original developer to do maintenance on components which were written long ago.
So, where are the recommended approaches for organizing and constructing large-scale applications for PHP (and Python, etc.)?
>No-one seems to understand that a distro might be chosen >for certain reasons and that changing is not an option, things >have to be made made to work.
I hear your point, but I think you are missing another one. What the parent was trying to say, I think, is that the technology exists in the open source community to do what you need to do. The fact that Distro X didn't pick up the technology and package it isn't the OSS community's fault - it's the distro packager's fault. So in other words, don't be so quick to judge the entire OSS community based on what specific people or companies have done (or said).
No, actually, you are still missing the point. The point being, the Open Source process is highly decentralized. This has many advantages -- no one disputes that in the two articles being discussed here.
But it also has several disadvantages. One of them is the chaos of multiple distributions. Another is terrible UI design. Neither of these serve users well, unless by "users" you are limiting the population down to the folks who actually care about the differences between Linux distributions.
Most of us don't. We want to get a Linux that works, and be done. We want to open our printer config panel, have it work, and be done. We don't want to think about, well, this distro has this, but that distro has that, so which one should I get?
That's madness, for most people.
O'Reilly offers "upgrade" pricing on all of their books. If you have an earlier edition, and buy the latest edition from them, you get 30% off the retail price. Proof of purchase is the ripped out title page.
A lot of folks have commented that this won't do anything to reduce spam, because spammers will just register new domains and send from those.
But, those new domains won't have any data in people's Bayesian corpus; they will be neutral in affecting spam probability scores.
On the other hand, domains that publish SPF records will be protecting their domain names, which means that those domain name tokens in people's Bayesian corpuses will count positively towards the message not being spam.
In other words, publishing SPF records for your domain can keep your domain from becoming a spam keyword in Bayesian filtering. I think this will likely improve the effectiveness of Bayesian filters overall.
SPF isn't a silver bullet -- and does not claim to be -- but every little bit helps.
I love the capability of Mac OS X to print anything to a PDF file, it's a great feature to use in a pinch. But it's no substitute for a real PDF generation tool, like Acrobat, or functionality built into OpenOffice.
The file size different noted here (22MB vs 2.3MB) is hardly unusual; indeed, it's the rule, not the exception. In dozens of attempts, I never made a PDF file remotely close to what Acrobat Distiller was capable of doing, size-wise.
If your job doesn't depend on being able to send people PDF files, the built-in version is fine. But if you share your PDFs regularly, spend the time or the bucks to get a real PDF solution.
I can personally recommend Java Software Solutions: Foundations of Program Design , by Lewis & Loftus. We used this textbook (the first edition, link above is the 3rd edition) in an introductory programming class, and it's very focused on program design first, Java second.
I will say, however, that a big part of what made the text successful in our class was the outstanding instructor, who gave a programming assignment every week, of his own design, rather than those from the book. Then again, I loaned my non-technical boss the book, to supplement her readings for the Java class she was taking, and she found it much more helpful than the text assigned by the instructor. In fact, she still hasn't returned it...
Another possibility would be Objects First with Java: A Practical Introduction Using BlueJ . BlueJ is an IDE specifically designed for the teaching of object-oriented programming, using Java. If you go to the BlueJ web site, you can learn more about the IDE (which is freely downloadable) and the pedagogical philosophies behind it.
I should say, I have not had personal experience with this text, just that it sounds like it might fit your requirements fairly well.
You don't understand SPEWS, or the word "innocent." If you are a customer of a spammer-friendly ISP (which is the only way SPEWS can hurt you), then you are a part of the problem, a silent collaborator with the spammers.
Patronizing spammer-friendly ISPs is almost as bad as actually buying things from spam. You're providing economic incentives to the people who make spam worth their while.
To be perfectly clear: if you're a customer of a spam-friendly ISP, you are supporting spam, and you deserve to be hit by SPEWS.
Yes, OmniWeb 4.5 is a major improvement in terms of quality of rendering and compatibility with more sites. And, as suggested, OmniGroup has indeed implemented features in their browser which would probably be impossible if they only used WebKit. This is a trivial one, but they automatically render hanging punctuation, rather than inline.
Go to http://www.happycog.com/lectures/dwws/ in both OmniWeb and Safari, and look at the placement of the opening quotation mark for the body copy to see this.
Minor feature only typographers will likely notice, but I'm sure there are many more instances where OmniGroup has added "fit-and-finish" to the raw materials provided by Apple.
If a company would come out with a cheap mini-pc just like the one in this article(no fans, small, etc) with 3 or 4 interfaces, I bet they would sell like hotcakes for use as cheap linux firewalls that don't take up a huge amount of space and don't sound like a jet engine all the time.
Soekris Engineering already has these. They build custom single-board PCs which are low-power and run fanless. They are not going to replace a PC for desktop use, but are terrific for firewalls, VPNs, wireless base stations, and the like.
They have several different models, with 2 or 3 network interfaces. The units with 2 interfaces have a slot to take a wireless PCCard to become a base station. They boot off compact flash, or tiny IDE drives. They can take a crypto hardware acceleration card. They can be powered by PoE (Power Over Ethernet).
The new net4801 takes the processor clock up to 233MHz. Like I said, not a speed demon, but it's a beautifully designed piece of hardware.
There's also a nice turnkey firewall package for the Soekris boxes, called m0n0wall, that's pretty functional and virtually idiot-proof. You could build a business selling these things, it's commercial quality polish.
Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front?
You might find Dominic Giampaolo's book about implementing the BeOS File System (BeFS) interesting:
Practical File System Design with the Be File System
by Dominic Giampaolo
* Paperback: 237 pages
* Publisher: Morgan Kaufmann (January 15, 1999)
* Average Customer Review: 4 out of 5 stars
I think Nielsen's wrong here. I find that, for certain types of searches, I want to look at the ads. No, really! Here's an example. My wife and I have one of those WhirleyPop stovetop popcorn popping gizmos. It works reasonably well with regular popcorn and oil, but it's really, really spectacular if you get the pre-measured packets of popcorn, oil, and seasonings.
Right before last Thanksgiving, I went to Amazon.com and searched for WhirleyPop. I could buy more poppers, but not more supplies. So I went to Google. Google's search results (for "popcorn & WhirleyPop") were OK, but the ads were exactly what I was looking for -- vendors who could sell me something, fairly specialized, that's never available in any store I visit.
In this case, it was the ads, not the search results, that were interesting. All of those people were ready to sell me exactly what I wanted. Sometimes, ads are not ads, they are the results themselves.
It says something about our crappy legal system that total crap like this can even be introduced into a court. There should be a pre-trial hearing to determine if something's even worthy of appearing in a court. No fancy legal bullshit, just some guy who looks at something and says, "that's fucking bullshit...trash can". Like the McD's coffee lawsuite, this is fucking bullshit and should have been trashed by the court clerks upon receiving it.
You obviously don't know the facts in the McDonald's coffee lawsuit. McDonald's was serving their coffee -- systematically, as part of the franchise way of doing things -- 30 degrees F higher than "hot", i.e., 180 degrees F instead of 150 F.
Metaphorically, it's a little like the difference between sending someone home with a gun that's not loaded and the safety on, vs. loaded, cocked, and safety off. One is dangerous, but well understood to be so, the other is unnecessarily, negligently dangerous.
Beyond that, McDonald's had a long history of complaints and actions regarding the overly hot coffee. In other words, they were not doing something dangerous unknowingly, they were doing it deliberately.
Regular coffee from your average coffee place will burn you if you spill it on yourself, but it's only a 2nd degree burn. The woman who spilled the coffee on herself suffered 3rd degree burns. Look the difference up in a medical dictionary, preferrably one with pictures, and then imagine yourself having it done to your privates, like she did.
Wonder if you'd think it was a frivolous lawsuit then.
Here's an annecdote. Earlier this year, I was building two new computers from components, for a new server and a desktop Linux system. I initially set out to make low-power, totally silent systems, based around the VIA C3 CPU.
But after doing research into cooling solutions, etc., I decided I could stand a tiny bit of noise, in exchange for greater processing power (I want to run Java web sites off the server box). So I upgraded the CPU to a Pentium III. This was possible, not just because the processors are opcode compatible, but because they were both Socket 370 compatible. Just swapped them out.
I would not have purchased an Intel CPU for the server system if I had made a commitment to a different socket format. So Intel would have lost.
More importantly, as a consumer, I won big time, by having a far more flexible system, that let me make an initial investment based on one set of requirements, and then upgrade the box later, when my requirements changed.
It's a shame that Intel doesn't want to keep this. After all, the C3 processor doesn't really compete with Intel's products -- there's quite a difference in processing power, at similar clock speeds. So let VIA have the low-power low end for us SilentPC enthusiasts, and own the rest. It's basic market segmentation, and Intel knows how to do that, profitably, very well.
I'd really like to see a simple plug-in that adds only one visible element to the standard interface, a smiley/frownie face, ala iCab, that indicates whether the HTML of the page actually validates to the DTD declared in the document itself. Clicking on a frownie face would bring up a list of validation errors. This would be a great tool for site developers, making mistakes quickly visible.
It would be an even better tool for standards evangelism if it was included in the default installation of Mozilla/Phoenix. Then you'd turn the entire population of Mozilla users into nitpickers, who would hound site developers about lack of standards compliance.
From personal experience, nothing makes you fix problems faster than users regularly sending you e-mail about things that are broken. So making it obvious when things are broken would lead to more feedback, and more feedback would lead to more standards-compliant websites.
Which would be good for Mozilla, and all other browser developers who work towards standards-compliance.
One of the things that's always struck me about X is that the type rendering is poor, compared to the state-of-the-art rendering on contemporary commercial OSes. This has been true, in my personal comparisons, over many years. (I.e., as X advances, so does the state-of-the-art, making relative progress nil.)
I remember when I worked at Be, we licensed a renderer from Bitstream, specifically because writing a really good type renderer is exceptionally hard.
Perhaps this is an area where Open Source nees a leg up from a well-funded commercial outfit, like Sun. Can anyone comment on the actual quality of this new library, relative to existing solutions?
What the fuck is wrong with these people? Why can't these developers just work on the fucking project and improve it and make it better without having to rewrite into yet another application? I had the exact same feeling when I saw the Phoenix announcement: WHY?!
I think you've missed the point of the Phoenix project. Have you actually used Phoenix? The browser UI is wonderful -- and that's impossible to achieve in the Mozilla project, because it has to be all things to all people.
Try taking the Is Phoenix Right For You quiz; if you like Mozilla better, great. If you don't, great.
Either way, stop complaining about what other people choose to do with their time.
I have a T68i that I use on the AT&T Wireless GSM network in the Bay Area.
For the most part, I get fine signal strength in all the places that I spend time at, and the phone works great...except at home. My neighborhood (Lower Haight in SF) has terrible coverage, and the phone is unusable.
That said, I was using a Nokia 8860 on AT&T's regular digital network, prior to the T68i, and it was only marginally better at home, and marginally worse elsewhere.
I think the T68i doesn't handle very low signal strength situations very well, but anything above that works fine for me.
While I'm certainly not a fan of the DMCA, I'm not sure this is a poor decision by the courts, etc. I think that it's probably reasonable for Lexmark to be able to forbid third-parties from selling supplies, if that's a business decision they want to make.
However, I don't think that, even if they ultimately win this case all the way up the line, that this is a winning business strategy. I certainly am not going to buy a printer that is tied exclusively to the manufacturer.
This can't be good publicity for Lexmark; every story is explaining that the manufacturer's supplies are more expensive. That's got to have consumers thinking about buying from HP, or Epson, or whomever.
I think this is a classic case of shooting yourself in the foot, and then sueing for the privilege of doing so again.
Can I hear from anyone who uses BBEdit -- what does it hvae that makes it so amazing?
I have been using (and paying for) BBEdit since version 3.something. It is the one piece of Mac OS software for which I order the upgrade first, and look at the new features second. It is one of my favorite pieces of software of all time. I've paid far more than $179 for my copies and upgrades, and consider it money well spent.
If you are a happy vi[m] or emacs user, don't bother to check BBEdit out. You won't like it, for the same reason that, while I can get around, I hate using vi (and never touch emacs). It's a different philosophy of application design.
BBEdit is a Mac OS application first. It conforms to all of the usual HI guidelines, but goes beyond that to provide an extremely well-designed, high-efficiency interface -- for Mac OS users. (vi folks will no doubt compare keystrokes to do the same task; apples to oranges, Mac OS folks don't want to have separate modes for commands vs. input. It goes back to the application philosophy.)
In spite of being Mac OS first, it provides nearly all of the tools and features you'd want in a text editor. Text munging, search-and-replace, grep manipulation, selection of columns, HTML-specific commands, glossaries, syntax highlighting, etc. I've yet to find its equal in a GUI-oriented application. (My favorite on Windows is TextPad, but it's a distant second.)
If you're a vi man, skip BBEdit. But if you're a Mac OS person, or aspiring to be so, you should give it a whirl.
Ummm, my understanding is that the standard Segway goes 12 MPH max.
Is 30 MPH a number you have a reference for?
The metadata that John Siracusa is asking for is actually very different. He's interested in seeing additional attributes added for files -- things like the file's MIME type, preferred handler, etc.
Be's BFS had all of these things, but not just as part of the journal. There was a lot more to BFS than just the journaling part!
This article contains a number of inaccuracies and omissions, which leads one to wonder if the author is not writing with rose-colored glasses firmly in place:
1. "BeOS is fully POSIX compliant" -- not correct; it would be more accurate to say "mostly" rather than fully. I could quote from the Be FAQs on this point, because I wrote the original FAQ (I worked at Be for three years).
2. USB & FireWire support -- the article states that the USB support is not very complete, and shortly thereafter implies that FireWire is supported more fully. It's really more the reverse, though I doubt if the USB code would work with much of the built-in USB hardware being released these days (you never know, though; we got the original stack from Intel). At any rate, if you happen to have a BeOS retail box, you'll see USB listed (along with the Intel credit), and no FireWire (though my most current box is for R4.5, not R5).
3. Design of the kernel -- I can't comment on a technical level, but my recollection of conversations with kernel engineers was more that the kernel was monolithic (and that we thought that was a good thing). The design inspiration was from the XINU operating system ("XINU" is "UNIX" backwards), I'll leave it to operating systems connoisseurs to determine whether that compares with the Hurd or L4, as the author asserts. Perhaps the author is thinking of a new kernel being written for the "not dead yet" OpenBeOS project(s).
In all, the article reminds me altogether too much of the many articles about the Amiga OS that I read while I worked at Be. Sad, but true. I wish those projects luck -- I miss Be and BeOS -- but I consider them wishful thinking. I've moved on to Mac OS X, and don't plan to go back.
Maybe the team now at Palm will change my mind -- I hope so!
A year and a half ago, my dot.bomb went under, and they gave us a pretty egregious agreement to sign. I signed it and turned it in, because I had not only severance (really, paying out of my vacation) but also several thousand dollars in expenses (training classes I'd put on my credit card).
However, upon further research and advice from others who had done this before, it turned out that I could have instead filed with the California Labor Board, and gotten not only the severance and expenses, but penalties if they were not paid in a timely fashion.
So, if I'd done some research, and been willing to go without the checks for a few extra weeks (or maybe a few months), I might have actually made more money not signing the agreement
In the end, though, the one-sided terms made the agreement a null contract; I was getting nothing (that I was not already entitled to by law), the company was getting something, and a valid contract requires that both parties actually get something from the other. I don't feel bound by the agreement (in areas like confidentiality, not talking trash, etc. -- though I don't have any reason to violate them either), and don't have any reason to test the more expensive clauses (not suing).
The real point here is, if you don't want to sign for some reason, look into your local labor laws. In California, the process for filing is (apparently) fairly simple, and the process of finding against the company is straightforward.
There are usually local organizations, usually not-for-profits, which can advise you of your rights and the law. Look for them via Google, if you can't find someone to give you a direct reference.
Good luck!
Dave Winer wrote a great article about this, in 1994. Everything holds true today.
Platform is Chinese Household
You're not building a "successful developer program," you're building a platform. The distinction is critical.