>the rest of the business world doesn't really seem to make time for "doing things right"
Software exists to solve problems.
If "doing things right" means solving a business need in the least expensive way possible, or in a way that costs a small amount now and will need more investment later, that tends to piss off developers, even though it may be the best thing to do from a business point of view.
If "doing things right" means spending trillions of dollars building new CPUs to run a brand new revolutionary programming language so you can spend eight more years writing a provably correct program that does something really fascinating but which no one can justify paying even $100 for, developers love that shit.
Plus, there's always some dick who will tell you that your program is a hack because it's lacking some feature that was never part of the requirements, but which they think every single program in the universe MUST have because they had to do it once. It has to run on 64-bit CPUs or it's a hack. It has to work on little-endian and big-endian CPUs or it's a hack. It has to work well in low memory situations, and handle multiple currencies, and support Hebrew, and have font smoothing, and a themed UI, and be portable to any GUI framework, and be multithreaded, and... blah blah blah. Developers are guilty of just as much scope creep as business stakeholders, but we hide it in the architecture instead of putting it in a feature list.
If you can't stand the idea of shipping something until you couldn't possibly think of any way to improve it, you definitely should stay in academia.
>even a fairly naive implementation in something like C or C++ (and perhaps Java) would probably have acheived the goal without having to make 5 optimization passes (and noticable time examining behavior).
How long would that have taken to write? More importantly, since it was the author and not you writing it, how long would it have taken him to write in C++?
The performance of the program is not the only thing that matters. The performance of the development team (of 1, in this case) matters too. This is the reason for the canonical "then why don't you just write everything in assembly" argument. I'm surprised at how many people in this thread don't see this, and are happy to replace that with "everything should be written in C++", as though all possible requirements are best addressed with C++ (and a tad of hand tuned assembly, of course!).
The right way to evaluate this is to include performance requirements with your functional specs. Once you have that, then the "right" architecture / language / process / team members etc. are the ones that let you satisfy the *complete* set of requirements (including features, maximum bug counts, and performance goals) in the shortest amount of time. This also addresses the argument in the other thread, regarding "but a slow 1.0 release is better than none." Sure, you could use a low-level programming language to squeeze out some more performance, but that's only important if the current performance isn't acceptable.
>the author claims it's fast enough, but I don't buy it. In any commercial setting,
Well, first of all it's a benchmark, so its purpose it is to measure relative performance. There is no particular performance goal. "Fast enough" doesn't even apply here. The author says he's impressed with how fast the initial trivial implementation is, but that doesn't equate to a hard performance target. For my uses, a Targa decoder could take all year, because I have exactly 0 Targa images that I need decoded.
Secondly, it's a little benchmark he whipped up to prove a point, and his point was that high-level optimizations yield more performance benefit than low-level ones (not calling a function is faster than inlining it, etc.) But it's not a commercial application, and nobody's asking you to buy it.
You might as well say "I won't pay the exorbitant $0 Winbench license fee for all the desktop users in my company because it doesn't run as fast as they need it to on modern PCs." Okaaaay....
>how can Apple sell the things with only 6 useful hours in a charge???
They don't. They sell it with 8, at least according to the spec sheet. Funny thing: I have one and I take it with me pretty much everywhere. When I'm near power, I'm usually also near a computer with speakers, so I plug it in and play songs off of it while it recharges via the same cable. No big deal. Having run out of battery only once or twice in over six months, I can't really remember how long it took. It's a non-issue for me, though I don't go for ten hour hikes, or whatever it is that you are planning to do with an MP3 player for which a unit with an 8 (or 6?) hour battery life would be "Useless".
I think that I had forgotten to plug it in for 2 or 3 days when it ran out of battery. That was a tragedy and I cried and cried and shouted to the heavens, "How can they sell something that needs to be recharged? So useless!" Then I hung myself. Oh the humanity. The neighbors shook their heads... "another iPod buyer who couldn't live with only 8 hours of continuous music, and decided to end it all."
Please.
My old Rio 500 had a 13 hour battery life off a single AA battery. That was horrible too. The battery life was longer, but I had to lug around this huge second AA battery, and actually take the old one out to recharge it.
P.S. the Jen MP3 player looks like a remote control from 1962, but who cares what the damn thing looks like since you'll most likely keep it in a pocket all the time. What matters most is how well it works.
Mod parent down; it's a troll. According to the Red Hat link in parent^2, Red Hat Desktop includes Evolution, OpenOffice.org, Mozilla, GAIM, etc. It's a GUI desktop.
Translation: Your story obviously sucks (even though I haven't read it); how dare you not pay more money so that I could read it (even though I've already decided that it sucks).
>1. People want vinyl records. They see it as a format from simpler times. They hate CDs for any number of reasons and vinyl lets them just listen to music.
I've never met anybody who thinks quite like that. Maybe the fact that you work in a record store affects your perceptions? People who want vinyl want it for retro kitsch reasons, so they can be a trendy DJ hipster.
CDs in no way prevent you from listening to music. WTF are you talking about? I guess I haven't seen any hand-cranked CD players but that hardly seems relevant as I haven't seen any LP walkmen either.
>4. The people who do know about DRM or any new formats have sworn to never use them.
Meanwhile, consumers buy DVDs in massive volume and don't whine about it. Yeah, there is piracy, but the simple fact that DVDs are so successful just goes to show how stupid the record industry is. If they had, for example, solidly embraced MiniDisc instead of switching to a DRM-less lossless medium, they might not be as fucked as they are now. No, I'm not a MiniDisc fan; I'm just making a point: DRM is wildly successful (in terms of adoption and resulting profits), except in the music industry.
>They made Java...., But IBM, Oracle and others have created thier own JDK's that are Java 1.4.x complinant as well.
This is a red herring. It doesn't cost anything to get a JVM from Sun. Sun has never been in a position to force Java developers to buy their JVM. They're still in the phase of desperately trying to keep developers interested.
IBM and Oracle have to pay Sun for the license to use the JVM source code. They aren't stealing some sort of cash cow JVM-selling business away from Sun.
So, no, you can't get it cheaper from IBM than Sun, but you did say "what does sun sell" so this doesn't apply anyway (they aren't selling it; they're giving it away).
I'd love to see the diffs between your version of the bible (complete with annotations like "clearly the literal word of god" and "just some myth meant to teach us a lesson") and, say, the King James version or maybe even the original texts.
Science doesn't explore; people do. Science is just a method, and sometimes people use it to refer to the body of knowledge that we currently hold to be true that was acquired via the scientific method. Scientists also peer-review each others' work, unless somebody is trying to hide something. That might mean that the researchers know their work won't hold up under scrutiny, or it might mean that the reviewers have an interest in the status quo and are trying to silence the new research. After all, if the work is bogus, it's a lot more powerful to bring it out in the open and point out all of the things that are wrong with it, than to say "nope, can't be true, lalalalalalala." Just because somebody thinks that the expedition won't find anything doesn't stop the people from going, provided somebody is willing to fund it and they can get whatever permits are necessary to go explore their target site.
When things get ugly is when someone claims to have performed an experiment that proves something new, and no respected scientific journals will publish it for whatever reason. Then you get cries of "conspiracy" which may or may not be true (it certainly has been true in the past). Sometimes the experiment is extremely badly designed and obviously can't prove anything, or maybe the researchers are pulling some kind of scam and don't want to subject themselves to scrutiny, but sometimes it's just plain resistance to change on the part of the science establishment.
Better than photos of something they claim to be the ark would be photos plus carbon dating results (and the results from a few other accepted dating techniques) a precise location of what they found. "It's up there somewhere; it was a miracle we found it" doesn't count.
I agree. Actually I have bought exactly one DRM'd album from Apple, out of curiosity. My goal was mainly to just see what the buying experience was like, but also to see what the quality of AAC was like.
I burned the album from DRM'd AAC to a CD-R, then ripped it with iTunes into MP3 format. Gee, that was hard. Of course the audiophiles had assured us all that the resulting sound quality would be unbearable, so I braced myself, and... it sounds totally fine. I didn't go so far as to actually do an A/B test (of an AIFF made from the CD, which should be the exact same data that was in the AAC file, spliced together with an AIFF made from the ripped MP3s) because I'm still not in love with the selection at the ITMS and I like to have liner notes and stuff anyway.
>Its rather nice not to change software in 3 years or so.
Sure, if you like using 4 or 5 year old hardware. If you want to use newer hardware, you have to run a "testing" kernel. Case in point: a 160GB hard disk attached to an ATA/133 card... gotta have 2.4.20 to handle it. I would have been limited to using 127MB of it, and accessing it thru the mobo's blazingly fast UltraDMA/33 ports, if I was determined to stay with "stable".
You've taken a valid problem that only affects a very small number of users, and blown it way out of proportion.
>Apple laptops are effectively unusable for unix users. It's a fairly safe argument that current Apple laptops are the among the most usable laptops ever made. Many, many articles have been written and awards given praising their excellent usability and design. They were specifically designed to run Apple's own Unix which ships preinstalled.
As far as I know there are no non-Unix operating systems that will run on directly on the hardware of current Apple laptops. (I'm lumping Linux in with Unix here.) I'm not 100% sure that somebody hasn't gotten AmigaOS or Be or something like that to run on current PB or iBook hardware, but even if they have, I doubt that there is even a single user in the whole wide world who uses anything like that as the primary OS on a current Apple laptop. It would be shocking indeed to find that they sold 157,000 PowerBooks and 217,000 iBooks last quarter if your claim that they were "effectively unusable" for all of their users were true.
>Apple is (currently) ignoring Unix users! This is not merely speculation on my part. No, it's a misunderstanding on your part, apparently reinforced by a single Apple employee who is either spreading incorrect information or whom you misunderstood. For Apple to ignore all Unix users would be to ignore all of their Mac OS X users.
>Apple has been ignoring Unix users for more than 13 years. Well, they must have ignored their A/UX users (I believe A/UX was discontinued about 9 years ago, which was when the AWS 95 was discontinued), and their Apple Network Server users as well (the ANS line was discontinued just over 7 years ago, and ran AIX), if your figure of 13 years is to be believed. I do agree that Apple is probably not paying a lot of attention to A/UX and Apple Network Server users lately.
In fact, all that your "more than 13 years" link shows is that there was somebody 13 years ago who wanted to remap his Mac's keyboard and didn't know how.
You make a huge leap in assuming that the majority of Unix users want their Ctrl and Caps Lock keys in the same place that you do, and that Apple's failure to reimplement their keyboard hardware interface proves that they are ignoring Unix users as a whole. The fact is, uControl fills this need for Mac OS X users.
If you have a genuine need to run OpenBSD or NetBSD on an Apple laptop, you could run it inside Bochs/WinTel or VirtualPC. I don't know of any good non-emulator virtualization layers for Mac OS X that are comparable to VMWare on x86; that is, ones that can run PPC on PPC without the overhead of emulation. (Panther has a Linux API compatibility layer, so it may be possible to compile User Mode Linux (which has been ported to PPC) so that you could run LinuxPPC on top of Mac OS X without emulation, but that doesn't get you OpenBSD or NetBSD.) However, since Mac OS X is Unix already, there isn't much need to run another PPC *nix on top of it, so I can understand why there don't seem to be any projects that provide this functionality. Likewise, I can see how Apple could be aware of the requirement that some users prefer that keyboard layout tweak, and could be satisfied with uControl + Mac OS X as the solution for that requirement. I'd like to hear what an Apple systems engineer or Apple Store "Genius" would have to say in response to your demand ("I want to run OpenBSD/NetBSD on one of your laptops instead of Mac OS X, so you have to re-engineer your keyboards to not use ADB anymore"). It would be pretty funny watching them try to be diplomatic in the face of such a request.
>How Unix friendly is a 1-button mouse with X prog
Real people care about vendor lock-in. They just don't think ahead, and fall into the trap that companies set for them. Only afterwards do they say "gee that sucks, I hate CaptiveCo for doing that to me."
Cars and washing machines don't apply - you don't have to buy special gas for your car; you don't have to drive on special Chevy roads. Washing machines and dryers don't require you to buy special clothes or special laundry detergent.
On the other hand, cell phones (in the US) were until recently tied to a provider, so if you had a fancy phone and wanted to switch, you had to buy a new phone. (I know that this has officially been changed, but I have read that there are still some more subtle techniques that companies are using to drag their feet.) Likewise, if you buy DRMd music, you're stuck with some bizarro infrastructure that has to be used for you to be able to listen to that music, be it an iPod or an audio player that supports WMA or whatever.
The lock-in on the iPod Mini (and the regular iPod) is mainly coming from the direction of the iTunes Music Store. Yes, you need iTunes to use the iPod Mini (although there is probably some project out there that lets you use one with Linux or whatever instead), but in a few years when you sell the Mini on eBay and buy something else, you won't have to buy all your CDs again just to use that new gizmo. (If you buy a bunch of DRM'd AAC files and then get rid of your iPod then you just might have to buy it all again.)
No, I think I'll let the people who are paid to maintain the software do this. I don't have enough free time to donate it right now, and even if I did, I have a number of enhancements on my to-do list for more important open-source projects that would come first. I'd also want some sort of assurance that if I went to the trouble of adding and QAing this feature, it would actually be used for/., because I really don't care about other users of Slashcode enough to spend the time it would take to do this just so that some teeny site I've never heard of could have this feature.
>as an ISP which they act as, they are obligated to transfer traffic when the studen pays for it.
Nonsense. First, there's almost certainly a set of terms of use which the student must agree to (and probably sign) in order to be allowed to use the network. Spam, porn, death threats, etc. are not things that a university or an ISP in general has any moral or legal obligation to allow just because a student has an account and may have paid for it. ISPs terminate spammers, shut down porn sites, and cancel user accounts for various kinds of forbidden behavior all the time.
Second, there are clearly some uses that any ISP has no obligation to allow, and has a fairly clear obligation to block for liability reasons, such as denial of service attacks, worm propagation attempts from exploted machines, etc. Some ISPs (including some of the largest national ones in the US) also block all port 25 traffic unless it's to their mail servers.
>when did you lose the right to trade copyrighted music online?
That depends on what you mean by "trade". If you're talking about allowing anonymous strangers to make complete copies of songs from your computer that are copyrighted and not authorized for this kind of distribution by the copyright holder, then you never had that right. There is no such right. The rights belong to the copyright holder, except for fair use. Allowing unlimited copies to be made for free and given to anonymous individuals is not fair use.
Maybe the song is copyrighted, but the copyright holder has authorized free online copying of the song. Maybe you know the person you're giving the copy to, and you know 100% for sure that they have a legal license to that song, such as from owning a CD. Those are mitigating circumstances.
Just because it's easy to commit a crime doesn't make it not a crime anymore. Little old ladies don't fight back as much big beefy ex-cons when you try to mug them, but that doesn't make it less illegal, or less wrong. It just makes it easier.
I have an idea for some amazing new technology. It's called "search". The/. editors would use this killer app to see if a given story had already been posted on their own web site. If a submitted "new" story contained a link that was also contained in a past story, that would be noted and links to the old stories would be provided so that the editor could see if the story was a duplicate.
Another wild new idea: moderating stories and having that affect the editors' karma. Oh wait, that isn't a new idea, it's just an idea that the editors have shot down. So we can choose not to read stories from individual editors, but we can't choose not to read stupid stories, or duplicate stories, or stories that the community has decided are stupid. We just have to assume that editors are consistently awful or consistently perfect.
That's pretty funny. Essentially, this is a feature that he's saying can potentially be used incorrectly, so they not only won't include it, but they say that a properly written application will include that feature itself.
---
I've just released my new RDBMS product, JamieSQL. It has no features whatsoever, takes no time to install, and is accessed via/dev/null for writes and/dev/random for reads. Application developers have no valid reason for storing data on a medium as unreliable as a disk, and if they need to do so, they should implement that functionality in the application itself. But if they need a quick way to store and retrieve that data, and reliability isn't an issue, then JamieSQL is perfect because it's faster than any other RDBMS in the world. If you'd like to pay our services group to run benchmarks for you to prove this, we'd be happy to. Just don't count on the data you wrote to/dev/null being returned from/dev/random in every case. (For boolean values we have seen up to 50% data corruption in internal tests, even when accompanied with a parity bit.) BTW, in this way JamieSQL also deviates from the ANSI SQL standard, but because I just admitted that, and that your data isn't necessarily going to be retrievable, these are features rather than bugs.
JamieSQL 2.0 now supports transactions. However, you must use the new/dev/zero API for reads, and be warned that in all cases, transactions will be rolled back and you will get zeroes (or null strings, if you prefer) for all column values upon subsequent reads. Again, this is not compatible with ANSI SQL behavior, but it's much faster, it's what we say people truly need, and because it's documented, it's a feature.
New! JamieSQL 3.0! With even better read performance for non-transactional workloads. The new/dev/urandom API has proven to be much more reliable and faster. Be aware that your data will not be returned in the same order as in the old 1.0/dev/random API. It's a feature.
FileMaker Pro first had relational functionality in version 3.0, way back in 1996. According to your linked article, in 7.0 they changed it so you can put multiple related tables into a single file.
FileMaker Pro has had relational functionality since version 3.0, released in early 1996. I used it for a one-to-many relation in my wedding invitation database way back in 1996. One table was for invitations, the other was for invitees on each invitation (a one-to-many relation).
msql also had some very serious bugs. It would periodically get confused and stop writing data to the disk, but would continue to process new SQL statements (including ones that changed data) as though it was working. Insert a row, it says OK, 1 row inserted. Select that row, 0 rows found. Kill and restart it and it's OK again, except you lost all the data that it forgot to write to disk. Duh.
After that I started caring about the quality of the RDBMS engine that I was using. The idea that it's better to write inherently complex and hard-to-test logic like transactions into each of your applications is very very weak. Concurrent programming is hard, period. Just because you haven't run across that race condition or corner case in your initial single-user development with your "QA lite" testing doesn't mean that it isn't going to happen when your app goes into production. Pretending that the problem doesn't exist doesn't make it go away.
Open source fans should be the first folks to say that the problem has already been well solved by package XYZ, so we should just use that instead of rolling our own.
>and i can do all the trigger, stored procedure stuff within the application code, big deal
Does your employer know that they are paying you to reimplement (and hopefully thoroughly test and debug) functionality that is already present in free software that you could have used if you felt like it?
"Well I could have used gzip but I thought that was too bloated, so I wrote my own compressor as part of the application you paid me to write."
>MySQL also allows you to do rapid development of small to medium sized projects.
How exactly does MySQL do a better job of letting you develop a SQL RDBMS system quickly than, say, PostgreSQL or SAP DB? It may be easier to install, and it may let you write code that fails to return an error message, but the only valid metric of software development productivity is how long it takes to write correct code. Otherwise you might as well use `/dev/random` as a source code generator. (A radical new rapid development methodology!)
Your story about the employee DB is pretty interesting. You could have used something other than MySQL, such as SAP DB or PostgreSQL or even Excel, and not had to buy Oracle. That proves nothing about MySQL's merits. I'll set up an employee contact list for you in 5 minutes in Excel (or OpenOffice if you prefer) that is perfectly suitable for the needs of a 25 person company. If the CTO insists on buying an Oracle license for something that could be done in Excel, that doesn't prove anything other than that your CTO wants to buy an Oracle license. Perhaps he wants to do this so that he won't have to keep paying you to reimplement functionality in every app that's already been in other RDBMSs for five years or more.
Slashdot Mirror
OK, so they put some memory sockets on a PCI card, made an ASIC that pretends to be an IDE controller or something, and they charge $999.00 for it.
No wonder I haven't heard of them before.
>the rest of the business world doesn't really seem to make time for "doing things right"
Software exists to solve problems.
If "doing things right" means solving a business need in the least expensive way possible, or in a way that costs a small amount now and will need more investment later, that tends to piss off developers, even though it may be the best thing to do from a business point of view.
If "doing things right" means spending trillions of dollars building new CPUs to run a brand new revolutionary programming language so you can spend eight more years writing a provably correct program that does something really fascinating but which no one can justify paying even $100 for, developers love that shit.
Plus, there's always some dick who will tell you that your program is a hack because it's lacking some feature that was never part of the requirements, but which they think every single program in the universe MUST have because they had to do it once. It has to run on 64-bit CPUs or it's a hack. It has to work on little-endian and big-endian CPUs or it's a hack. It has to work well in low memory situations, and handle multiple currencies, and support Hebrew, and have font smoothing, and a themed UI, and be portable to any GUI framework, and be multithreaded, and... blah blah blah. Developers are guilty of just as much scope creep as business stakeholders, but we hide it in the architecture instead of putting it in a feature list.
If you can't stand the idea of shipping something until you couldn't possibly think of any way to improve it, you definitely should stay in academia.
>even a fairly naive implementation in something like C or C++ (and perhaps Java) would probably have acheived the goal without having to make 5 optimization passes (and noticable time examining behavior).
How long would that have taken to write? More importantly, since it was the author and not you writing it, how long would it have taken him to write in C++?
The performance of the program is not the only thing that matters. The performance of the development team (of 1, in this case) matters too. This is the reason for the canonical "then why don't you just write everything in assembly" argument. I'm surprised at how many people in this thread don't see this, and are happy to replace that with "everything should be written in C++", as though all possible requirements are best addressed with C++ (and a tad of hand tuned assembly, of course!).
The right way to evaluate this is to include performance requirements with your functional specs. Once you have that, then the "right" architecture / language / process / team members etc. are the ones that let you satisfy the *complete* set of requirements (including features, maximum bug counts, and performance goals) in the shortest amount of time. This also addresses the argument in the other thread, regarding "but a slow 1.0 release is better than none." Sure, you could use a low-level programming language to squeeze out some more performance, but that's only important if the current performance isn't acceptable.
>the author claims it's fast enough, but I don't buy it. In any commercial setting,
Well, first of all it's a benchmark, so its purpose it is to measure relative performance. There is no particular performance goal. "Fast enough" doesn't even apply here. The author says he's impressed with how fast the initial trivial implementation is, but that doesn't equate to a hard performance target. For my uses, a Targa decoder could take all year, because I have exactly 0 Targa images that I need decoded.
Secondly, it's a little benchmark he whipped up to prove a point, and his point was that high-level optimizations yield more performance benefit than low-level ones (not calling a function is faster than inlining it, etc.) But it's not a commercial application, and nobody's asking you to buy it.
You might as well say "I won't pay the exorbitant $0 Winbench license fee for all the desktop users in my company because it doesn't run as fast as they need it to on modern PCs." Okaaaay....
>how can Apple sell the things with only 6 useful hours in a charge???
They don't. They sell it with 8, at least according to the spec sheet. Funny thing: I have one and I take it with me pretty much everywhere. When I'm near power, I'm usually also near a computer with speakers, so I plug it in and play songs off of it while it recharges via the same cable. No big deal. Having run out of battery only once or twice in over six months, I can't really remember how long it took. It's a non-issue for me, though I don't go for ten hour hikes, or whatever it is that you are planning to do with an MP3 player for which a unit with an 8 (or 6?) hour battery life would be "Useless".
I think that I had forgotten to plug it in for 2 or 3 days when it ran out of battery. That was a tragedy and I cried and cried and shouted to the heavens, "How can they sell something that needs to be recharged? So useless!" Then I hung myself. Oh the humanity. The neighbors shook their heads... "another iPod buyer who couldn't live with only 8 hours of continuous music, and decided to end it all."
Please.
My old Rio 500 had a 13 hour battery life off a single AA battery. That was horrible too. The battery life was longer, but I had to lug around this huge second AA battery, and actually take the old one out to recharge it.
P.S. the Jen MP3 player looks like a remote control from 1962, but who cares what the damn thing looks like since you'll most likely keep it in a pocket all the time. What matters most is how well it works.
Mod parent down; it's a troll. According to the Red Hat link in parent^2, Red Hat Desktop includes Evolution, OpenOffice.org, Mozilla, GAIM, etc. It's a GUI desktop.
Translation: Your story obviously sucks (even though I haven't read it); how dare you not pay more money so that I could read it (even though I've already decided that it sucks).
>1. People want vinyl records. They see it as a format from simpler times. They hate CDs for any number of reasons and vinyl lets them just listen to music.
I've never met anybody who thinks quite like that. Maybe the fact that you work in a record store affects your perceptions? People who want vinyl want it for retro kitsch reasons, so they can be a trendy DJ hipster.
CDs in no way prevent you from listening to music. WTF are you talking about? I guess I haven't seen any hand-cranked CD players but that hardly seems relevant as I haven't seen any LP walkmen either.
>4. The people who do know about DRM or any new formats have sworn to never use them.
Meanwhile, consumers buy DVDs in massive volume and don't whine about it. Yeah, there is piracy, but the simple fact that DVDs are so successful just goes to show how stupid the record industry is. If they had, for example, solidly embraced MiniDisc instead of switching to a DRM-less lossless medium, they might not be as fucked as they are now. No, I'm not a MiniDisc fan; I'm just making a point: DRM is wildly successful (in terms of adoption and resulting profits), except in the music industry.
Thank goodness. I was really getting tired of finding that people had written "WASH ME" in the pollen that's all over my bees.
I'm curious to see how a hard drive can clean a bee, though.
>They made Java...., But IBM, Oracle and others have created thier own JDK's that are Java 1.4.x complinant as well.
This is a red herring. It doesn't cost anything to get a JVM from Sun. Sun has never been in a position to force Java developers to buy their JVM. They're still in the phase of desperately trying to keep developers interested.
IBM and Oracle have to pay Sun for the license to use the JVM source code. They aren't stealing some sort of cash cow JVM-selling business away from Sun.
So, no, you can't get it cheaper from IBM than Sun, but you did say "what does sun sell" so this doesn't apply anyway (they aren't selling it; they're giving it away).
I'd love to see the diffs between your version of the bible (complete with annotations like "clearly the literal word of god" and "just some myth meant to teach us a lesson") and, say, the King James version or maybe even the original texts.
>Science should not be afraid to explore, period.
Science doesn't explore; people do. Science is just a method, and sometimes people use it to refer to the body of knowledge that we currently hold to be true that was acquired via the scientific method. Scientists also peer-review each others' work, unless somebody is trying to hide something. That might mean that the researchers know their work won't hold up under scrutiny, or it might mean that the reviewers have an interest in the status quo and are trying to silence the new research. After all, if the work is bogus, it's a lot more powerful to bring it out in the open and point out all of the things that are wrong with it, than to say "nope, can't be true, lalalalalalala." Just because somebody thinks that the expedition won't find anything doesn't stop the people from going, provided somebody is willing to fund it and they can get whatever permits are necessary to go explore their target site.
When things get ugly is when someone claims to have performed an experiment that proves something new, and no respected scientific journals will publish it for whatever reason. Then you get cries of "conspiracy" which may or may not be true (it certainly has been true in the past). Sometimes the experiment is extremely badly designed and obviously can't prove anything, or maybe the researchers are pulling some kind of scam and don't want to subject themselves to scrutiny, but sometimes it's just plain resistance to change on the part of the science establishment.
Better than photos of something they claim to be the ark would be photos plus carbon dating results (and the results from a few other accepted dating techniques) a precise location of what they found. "It's up there somewhere; it was a miracle we found it" doesn't count.
I agree. Actually I have bought exactly one DRM'd album from Apple, out of curiosity. My goal was mainly to just see what the buying experience was like, but also to see what the quality of AAC was like.
I burned the album from DRM'd AAC to a CD-R, then ripped it with iTunes into MP3 format. Gee, that was hard. Of course the audiophiles had assured us all that the resulting sound quality would be unbearable, so I braced myself, and... it sounds totally fine. I didn't go so far as to actually do an A/B test (of an AIFF made from the CD, which should be the exact same data that was in the AAC file, spliced together with an AIFF made from the ripped MP3s) because I'm still not in love with the selection at the ITMS and I like to have liner notes and stuff anyway.
>Its rather nice not to change software in 3 years or so.
Sure, if you like using 4 or 5 year old hardware. If you want to use newer hardware, you have to run a "testing" kernel. Case in point: a 160GB hard disk attached to an ATA/133 card... gotta have 2.4.20 to handle it. I would have been limited to using 127MB of it, and accessing it thru the mobo's blazingly fast UltraDMA/33 ports, if I was determined to stay with "stable".
You've taken a valid problem that only affects a very small number of users, and blown it way out of proportion.
>Apple laptops are effectively unusable for unix users.
It's a fairly safe argument that current Apple laptops are the among the most usable laptops ever made. Many, many articles have been written and awards given praising their excellent usability and design. They were specifically designed to run Apple's own Unix which ships preinstalled.
As far as I know there are no non-Unix operating systems that will run on directly on the hardware of current Apple laptops. (I'm lumping Linux in with Unix here.) I'm not 100% sure that somebody hasn't gotten AmigaOS or Be or something like that to run on current PB or iBook hardware, but even if they have, I doubt that there is even a single user in the whole wide world who uses anything like that as the primary OS on a current Apple laptop. It would be shocking indeed to find that they sold 157,000 PowerBooks and 217,000 iBooks last quarter if your claim that they were "effectively unusable" for all of their users were true.
>Apple is (currently) ignoring Unix users! This is not merely speculation on my part.
No, it's a misunderstanding on your part, apparently reinforced by a single Apple employee who is either spreading incorrect information or whom you misunderstood. For Apple to ignore all Unix users would be to ignore all of their Mac OS X users.
>Apple has been ignoring Unix users for more than 13 years.
Well, they must have ignored their A/UX users (I believe A/UX was discontinued about 9 years ago, which was when the AWS 95 was discontinued), and their Apple Network Server users as well (the ANS line was discontinued just over 7 years ago, and ran AIX), if your figure of 13 years is to be believed. I do agree that Apple is probably not paying a lot of attention to A/UX and Apple Network Server users lately.
In fact, all that your "more than 13 years" link shows is that there was somebody 13 years ago who wanted to remap his Mac's keyboard and didn't know how.
You make a huge leap in assuming that the majority of Unix users want their Ctrl and Caps Lock keys in the same place that you do, and that Apple's failure to reimplement their keyboard hardware interface proves that they are ignoring Unix users as a whole. The fact is, uControl fills this need for Mac OS X users.
If you have a genuine need to run OpenBSD or NetBSD on an Apple laptop, you could run it inside Bochs/WinTel or VirtualPC. I don't know of any good non-emulator virtualization layers for Mac OS X that are comparable to VMWare on x86; that is, ones that can run PPC on PPC without the overhead of emulation. (Panther has a Linux API compatibility layer, so it may be possible to compile User Mode Linux (which has been ported to PPC) so that you could run LinuxPPC on top of Mac OS X without emulation, but that doesn't get you OpenBSD or NetBSD.) However, since Mac OS X is Unix already, there isn't much need to run another PPC *nix on top of it, so I can understand why there don't seem to be any projects that provide this functionality. Likewise, I can see how Apple could be aware of the requirement that some users prefer that keyboard layout tweak, and could be satisfied with uControl + Mac OS X as the solution for that requirement. I'd like to hear what an Apple systems engineer or Apple Store "Genius" would have to say in response to your demand ("I want to run OpenBSD/NetBSD on one of your laptops instead of Mac OS X, so you have to re-engineer your keyboards to not use ADB anymore"). It would be pretty funny watching them try to be diplomatic in the face of such a request.
>How Unix friendly is a 1-button mouse with X prog
Real people care about vendor lock-in. They just don't think ahead, and fall into the trap that companies set for them. Only afterwards do they say "gee that sucks, I hate CaptiveCo for doing that to me."
Cars and washing machines don't apply - you don't have to buy special gas for your car; you don't have to drive on special Chevy roads. Washing machines and dryers don't require you to buy special clothes or special laundry detergent.
On the other hand, cell phones (in the US) were until recently tied to a provider, so if you had a fancy phone and wanted to switch, you had to buy a new phone. (I know that this has officially been changed, but I have read that there are still some more subtle techniques that companies are using to drag their feet.) Likewise, if you buy DRMd music, you're stuck with some bizarro infrastructure that has to be used for you to be able to listen to that music, be it an iPod or an audio player that supports WMA or whatever.
The lock-in on the iPod Mini (and the regular iPod) is mainly coming from the direction of the iTunes Music Store. Yes, you need iTunes to use the iPod Mini (although there is probably some project out there that lets you use one with Linux or whatever instead), but in a few years when you sell the Mini on eBay and buy something else, you won't have to buy all your CDs again just to use that new gizmo. (If you buy a bunch of DRM'd AAC files and then get rid of your iPod then you just might have to buy it all again.)
No, I think I'll let the people who are paid to maintain the software do this. I don't have enough free time to donate it right now, and even if I did, I have a number of enhancements on my to-do list for more important open-source projects that would come first. I'd also want some sort of assurance that if I went to the trouble of adding and QAing this feature, it would actually be used for /., because I really don't care about other users of Slashcode enough to spend the time it would take to do this just so that some teeny site I've never heard of could have this feature.
>as an ISP which they act as, they are obligated to transfer traffic when the studen pays for it.
Nonsense. First, there's almost certainly a set of terms of use which the student must agree to (and probably sign) in order to be allowed to use the network. Spam, porn, death threats, etc. are not things that a university or an ISP in general has any moral or legal obligation to allow just because a student has an account and may have paid for it. ISPs terminate spammers, shut down porn sites, and cancel user accounts for various kinds of forbidden behavior all the time.
Second, there are clearly some uses that any ISP has no obligation to allow, and has a fairly clear obligation to block for liability reasons, such as denial of service attacks, worm propagation attempts from exploted machines, etc. Some ISPs (including some of the largest national ones in the US) also block all port 25 traffic unless it's to their mail servers.
>when did you lose the right to trade copyrighted music online?
That depends on what you mean by "trade". If you're talking about allowing anonymous strangers to make complete copies of songs from your computer that are copyrighted and not authorized for this kind of distribution by the copyright holder, then you never had that right. There is no such right. The rights belong to the copyright holder, except for fair use. Allowing unlimited copies to be made for free and given to anonymous individuals is not fair use.
Maybe the song is copyrighted, but the copyright holder has authorized free online copying of the song. Maybe you know the person you're giving the copy to, and you know 100% for sure that they have a legal license to that song, such as from owning a CD. Those are mitigating circumstances.
Just because it's easy to commit a crime doesn't make it not a crime anymore. Little old ladies don't fight back as much big beefy ex-cons when you try to mug them, but that doesn't make it less illegal, or less wrong. It just makes it easier.
I have an idea for some amazing new technology. It's called "search". The /. editors would use this killer app to see if a given story had already been posted on their own web site. If a submitted "new" story contained a link that was also contained in a past story, that would be noted and links to the old stories would be provided so that the editor could see if the story was a duplicate.
Another wild new idea: moderating stories and having that affect the editors' karma. Oh wait, that isn't a new idea, it's just an idea that the editors have shot down. So we can choose not to read stories from individual editors, but we can't choose not to read stupid stories, or duplicate stories, or stories that the community has decided are stupid. We just have to assume that editors are consistently awful or consistently perfect.
That's pretty funny. Essentially, this is a feature that he's saying can potentially be used incorrectly, so they not only won't include it, but they say that a properly written application will include that feature itself.
/dev/null for writes and /dev/random for reads. Application developers have no valid reason for storing data on a medium as unreliable as a disk, and if they need to do so, they should implement that functionality in the application itself. But if they need a quick way to store and retrieve that data, and reliability isn't an issue, then JamieSQL is perfect because it's faster than any other RDBMS in the world. If you'd like to pay our services group to run benchmarks for you to prove this, we'd be happy to. Just don't count on the data you wrote to /dev/null being returned from /dev/random in every case. (For boolean values we have seen up to 50% data corruption in internal tests, even when accompanied with a parity bit.) BTW, in this way JamieSQL also deviates from the ANSI SQL standard, but because I just admitted that, and that your data isn't necessarily going to be retrievable, these are features rather than bugs.
/dev/zero API for reads, and be warned that in all cases, transactions will be rolled back and you will get zeroes (or null strings, if you prefer) for all column values upon subsequent reads. Again, this is not compatible with ANSI SQL behavior, but it's much faster, it's what we say people truly need, and because it's documented, it's a feature.
/dev/urandom API has proven to be much more reliable and faster. Be aware that your data will not be returned in the same order as in the old 1.0 /dev/random API. It's a feature.
---
I've just released my new RDBMS product, JamieSQL. It has no features whatsoever, takes no time to install, and is accessed via
JamieSQL 2.0 now supports transactions. However, you must use the new
New! JamieSQL 3.0! With even better read performance for non-transactional workloads. The new
FileMaker Pro first had relational functionality in version 3.0, way back in 1996. According to your linked article, in 7.0 they changed it so you can put multiple related tables into a single file.
FileMaker Pro has had relational functionality since version 3.0, released in early 1996. I used it for a one-to-many relation in my wedding invitation database way back in 1996. One table was for invitations, the other was for invitees on each invitation (a one-to-many relation).
FileMaker Pro 3.0 from Claris Goes Relational
FileMaker Pro 3.0 Has Relational Powers
msql also had some very serious bugs. It would periodically get confused and stop writing data to the disk, but would continue to process new SQL statements (including ones that changed data) as though it was working. Insert a row, it says OK, 1 row inserted. Select that row, 0 rows found. Kill and restart it and it's OK again, except you lost all the data that it forgot to write to disk. Duh.
After that I started caring about the quality of the RDBMS engine that I was using. The idea that it's better to write inherently complex and hard-to-test logic like transactions into each of your applications is very very weak. Concurrent programming is hard, period. Just because you haven't run across that race condition or corner case in your initial single-user development with your "QA lite" testing doesn't mean that it isn't going to happen when your app goes into production. Pretending that the problem doesn't exist doesn't make it go away.
Open source fans should be the first folks to say that the problem has already been well solved by package XYZ, so we should just use that instead of rolling our own.
>and i can do all the trigger, stored procedure stuff within the application code, big deal
Does your employer know that they are paying you to reimplement (and hopefully thoroughly test and debug) functionality that is already present in free software that you could have used if you felt like it?
"Well I could have used gzip but I thought that was too bloated, so I wrote my own compressor as part of the application you paid me to write."
>MySQL also allows you to do rapid development of small to medium sized projects.
How exactly does MySQL do a better job of letting you develop a SQL RDBMS system quickly than, say, PostgreSQL or SAP DB? It may be easier to install, and it may let you write code that fails to return an error message, but the only valid metric of software development productivity is how long it takes to write correct code. Otherwise you might as well use `/dev/random` as a source code generator. (A radical new rapid development methodology!)
Your story about the employee DB is pretty interesting. You could have used something other than MySQL, such as SAP DB or PostgreSQL or even Excel, and not had to buy Oracle. That proves nothing about MySQL's merits. I'll set up an employee contact list for you in 5 minutes in Excel (or OpenOffice if you prefer) that is perfectly suitable for the needs of a 25 person company. If the CTO insists on buying an Oracle license for something that could be done in Excel, that doesn't prove anything other than that your CTO wants to buy an Oracle license. Perhaps he wants to do this so that he won't have to keep paying you to reimplement functionality in every app that's already been in other RDBMSs for five years or more.