TIFF is a huge mess. Let's face it; it's a gigantic cockup. Anyone can write TIFF files, but they're nearly impossible to "read" in the sense that a user is going to expect: if I say that my application will "read TIFFs," they're going to expect that anything with a TIF extension is going to get read. And that's almost never the case; you can pack just too much stuff into the container.
I fail to see how DNG is going to be any different from this. They've already said that there are going to be multiple versions of it as it evolves, and it is already a limited subset of tiff - which, by the way, isn't terribly efficient.
We need to have something that does at least as well as zip for lossless stuff, (that's probably okay with DNG since Adobe is trying to get it use for cameras), and wavelet transforms for lossy stuff. Personally, I'd prefer that this means that we standardize on two formats.
You may be thinking, "but we have jpeg for lossy." Why isn't this enough? The answer is maps. Those suckers are huge, but you want to put them on tiny devices for navigating. Further, you want it to be easy to zoom in to really small resolutions without seeing horrible artifacts. DWT does this much, much better than DCT.
You like DNG for one? Works for me. Existing TIFF readers can be retrofitted to read DNG. I suspect, though, that this format will get about as much play time as PNG gets now. Given a JP2 and a DNG that's 95% larger, but both look almost identical, which do you think people will want to use in their portable devices?
Right now I'm still thinking that jpeg2000 is good for general purpose use (when you care about storage space more than processing power - which is almost all of the time). It's already got support in a lot of apps and is well understood. I imagine that as images get bigger, the desire to use this space-saving format, or another one that uses DWT will probably creep in.
Actually it would. Microsoft Office Crapware Edition comes loaded on most of prebuilt computers. It's a trial use version of Office.
I bet Microsoft is doing something for them for the privilege of putting that thing on there. I bet that Microsoft wouldn't be willing to do whatever that is if something better than Office Crapware was also installed.
Insightful, but only half right. Same for the original poster and the GP.
The puncher doesn't fly backwards because his fist is gradually accellerated over a period of time (say 0.3 seconds). The Newtonian reaction to this is a backwards-pushing force that is small enough to be countered by the friction between his feet and the floor.
That has nothing to do with when he actually hits, however. The mass that is being pushed forward is a small one - the mass of his arm. Remember, Force=Mass*Acceleration. You can accelerate that thing pretty fast because the mass is small, not because you're doing it gradually. You can't punch hard enough to throw the rest of you backward and rip your arm off even if you're accelerating it faster than gravity.
When you actually connect, you put *more force* into the blow while you're hitting.
Re:right....
on
DIY Laptop
·
· Score: 3, Informative
Entry level boards from both Xilinx and Altera run about $50. Personally, I think it's worth it to spring for the $200 models since you get all kinds of useful things already on it (like RAM), but the $50 ones are out there. Here's some examples.
Re:right....
on
DIY Laptop
·
· Score: 3, Interesting
A $50 FPGA can be made to work as a 256 color VGA driver (or any size lcd controller you like), and you can easily get it to accept PS/2 input from a keyboard.
Then you pick your poison for processors, coprocessors, etc - as long as it fits on the FPGA.
user can type away in a standard TEXTAREA field and know when some predefined text area in a PDF document is full......but the ONLY browser specific problem I ran into was...
No offense, but that means that you don't know much (or forgot about) the major incompatibilities between browsers. There's a great, sleeping dragon that you just barely skirted.
I assume you're attaching an "onkeypress" or "onchange" event to the textarea. That would be the logical approach to that.
Lets say that you liked your code and decided to implement it on another form, only this form is written to validate the entire form when you finish everything using some clever framework-generated javascript - maybe rails, maybe struts...whatever.
Does your code still work the same in both browsers?
No - because DOM event-compliant browsers and IE both bubble events differently. Fixing these two to work together in one browser won't fix them in the other. You have to have special cases to deal with both varieties. And that ends up being a huge pain if your framework didn't think of this to help ensure that every node with a listener on it gets to actually see its events.
This is the fundamental problem that means that everyone always has to check for cross compatibility. Without events, javascript isn't dynamic. Without events, everything that javascript does can be done either server-side or with straight HTML. Events are the core of javascript, and they work differently depending on the browser.
The is only the biggest problem. There are others. Most notably, there are some parts of IE that won't even accept events. You have to keep in mind which parts those are and basically not use them in Mozilla at all if you want your script to work everywhere.
And now something completely different...I've identified a real problem. Now I'd like to address what I see as a nonproblem. Stuff that relates to the DOM often differ from browser to browser while the core language does not.
Where exactly are you getting this? IE accepts all of the node addressing features of the DOM. While the event framework isn't supported (and it certainly isn't core to the functionality of DOM; it was tacked on afterward), anything at all that can get events through other means can get them through the DOM.
As an example, here are the crucial DOM functions that I use that work in IE the same way that they do in Mozilla (a lot of these will work with any node object from the DOM; some are restricted to the global variable "document"): getElementByID,getElementsByName,attachEvent,detac hEvent,getElementsByTagName,childNodes,parent
That covers the vast majority of scripts out there that use the DOM. Because IE has it's own special way of addressing things, you're more likely to cover everybody if you *do* use the DOM rather than not, since IE supports those things too. Which functions are you referring to that it doesn't support?
It's not as cut and dried as all that. They should already have java 5 packages, and stuff that uses them.
Well, this is the reference implementation of such a package. Further, since its all done according to a VM spec, it mostly just works.
Given all that, the amount of testing needed shouldn't be as much as it is for other packages. I don't care about waiting for the latest unstable release of some package put out by one guy in his basement, but this isn't that. It's a HUGE player with its own testing department.
My distro doesn't focus on bleeding edge. I don't use bleeding edge. They spent a whole *year* in Gentoo getting ready for a smooth Java 5 migration. (It *used* to be bleeding edge, but it hasn't been for about five years).
I expect that no matter what distro it is, there should be a level of pragmatism. It shouldn't take anybody as long as its been to test everything to their satisfaction. The fact that it does means there's more red tape than their needs to be.
I see a lot of myopia on these threads on this subject; this isn't a complaint trying to get some free stuff/getting it faster/getting people to do stuff for me. It's an observation that Debian isn't doing well compared to other distros. There's something wrong with it if it takes hundreds of times as long to mark something as stable as most of the rest of the distros take.
Twice as long, maybe - maybe even four times as long. But I think they're pushing the length of time these things take to the point that what they're doing is something besides testing. Maybe they don't have the people for real tests, or maybe they have a lot of red tape. I don't know. I'd just rather not use a distro with so little impetus when there are ones that other people are working on more diligently.
Entitlement? Okay, sure. Yeah. I want Debian to do me the "huge freaking favor" of downloading the jdk and keeping track of what's in the file system.
How long does that take? I know it'd take me about five minutes (and it *shouldn't* take more for any reasonable package management system)...what is that amortized over all the users of Debian? I'm sure it comes to less than a second each. I think you may be exaggerating how much of a favor it would be for a Debian user - though I am not one.
This has nothing to do with what I want. I don't care one way or the other what Debian does. If I did I'd probably be involved in it.
Well...that's not quite true. Because I know that I have to either use unstable packages or deal with not getting stable stuff until way later, I have decided not to have anything to do with Debian. Otherwise I might be using it now. If Debian was the only choice, of course, I'd use it and be thankful for it.
You don't think the fact that people naturally think imperatively and not functionally has no bearing on the situation?
When it's the difference between lisp, which was marginally easier to develop with once you understood it, or cobol, which was easier to understand, but harder to develop with once you knew it, which do you think people would choose?
Cobol more than nine times out of ten...and with the increase in coders, there was an increase in available code. Pathways to solve common problems were made and LISP's natural ease-of-devel benefit was taken away.
If I can make a prediction about current techs, I would say that this is why things like ActiveRecord are going to beat out complex ORMs like Hibernate. There are a lot of other things with that same possibility.
SOAP versus XML-RPC, Oracle versus every other database system on the planet, and Java versus high level scripting languages that can also run on VMs.
Of course, with mitigating factors like throwing money at the problems, I could end up wrong about these. But I think that's the way that things are currently progressing: when the margin of difference is small enough, the initial learning curve makes all the difference in the world.
The best best case sort you can get is n. An optimal algorithm would always hit that.
What it has is the optimal worst case, which is not the same thing at all.
When picking a sorting algorithm, you have to consider the best, worse, and average cases, and specifically how it deals with the kind of dataset you have.
Mergesort's best, worst, and average cases are all the same - nLog(n) It's sort of like a compromise. It's not really fast at any particular case, but, then again, it's never bad.
If your data is perfectly random, or you know nothing about it, then merge sort is your algorithm.
However, on semi-sorted data, quicksort performs better or worse than merge sort. Better if it's almost sorted in the correct order, (O(n) if it is sorted in the right order), or worse if it's sorted mostly in reverse order O(n^2) if entirely in reverse order.
Most data that is created by humans is partially sorted (i.e. in human data entry cases)...so there are many places that quicksort is usually a better choice. However, given any unknown set sample, there is a much higher likelihood that the set will be mostly random - meaning on average when considering all possible sets, mergesort performs better.
These are the two extremes in the sorting world - quicksort has best best case, but the worst worst case, while merge sort has the best worst case, and the worst best case.
All other sorting algorithms that are considered efficient fall between these two extremes and take advantage of some piece of knowledge about the data (keep in mind that sorting algorithms in general *don't* distinguish between in-place and not in-place. This is almost universally a trivial detail that doesn't effect the order of the algorithm) that lets you do better than O(nLog(n)) on that specific kind of data.
It always seems strange to me that people learn what these two algorithms are without learning how they define the boundaries of the solution space. If you don't know what they're for then what's the point of learning more than one at all then?
Read better. I qualified the point where perl is useful. I'll elaborate anyway. Unlike heroin and a defective lighter, perl is useful to me and to other developers for throw away code (i.e. stuff you're only going to use once), for small projects, and for heavily QAed coding.
Any of these approaches do a good job of guaranteeing that you won't have any problems with sloppiness. I would go so far as to saying that in the first two cases - small projects and throw away code are both very good places to use perl. You get your results much faster than if you have to fit things into another language.
Perl makes a very good shell language. It's also good as a configuration language and a text transformation language, specifically because all of these jobs are small and often throw-away. These are just a few things that I can think of off of the top of my head.
KISS is hard. Very hard. It's different in different places. Sometimes keeping it simple means writing less code. Sometimes it means creating a new sub-language that better describes your problem.
In perl, you can change the nature of the language itself. *Everything* can be changed. The idea is that if there is more than one way to do it, then you can do it the simplest way for whatever definition of simple is required.
Maintaining consistency is up to the developer himself. Obviously, those tempted to succumb to the lure of sloppiness (which, unfortunately, in my experience, is every perl programmer I've ever met including myself) shouldn't use perl for really big projects. You can't blame the language for giving you that freedom, though.
Perl is where it is because you don't have to change the way that you think in order to program in it. Perl will change how it works to match how you think, which makes it more convenient than almost any other language.
That particular behavior is what makes it possible to have so many perl modules in existane, which in turn is responsible for the popularity. It's also why about half of those modules have bugs so horrible that they're unusable. It's certainly a tradeoff.
There's no reason for this. We use these words to describe things that we don't have a good way of describing other ways (like sound...the only word that means "having more undertones than the characteristic tone of the sound producer" is "warm.")
But there are more words for light than there are for any other sense because our brains process vision better than we process anything else. There's no need to use touch words to describe light.
So...what does what you said just mean using visual adjectives?
I feel like you're approaching this from the wrong side.
IMHO, the best binary installer is apt. It's got the most features that work. Similarly, the best source installer is Portage. So what I think we really need is something that works a bit like both.
Bearing that in mind, you must also consider that portage was basically designed as an improvement of ports and apt. It's got a lot of the same features. Here's the deal, though: a source installer needs to be able to do everything that a binary installer can, and it must also be able to do a lot more. It needs to check for variables dependencies, and handle package compile options, downloading code from repositories, and sometimes dynamic dependency resolution. Of course, it also has to handle exactly the same things that apt does - installing binary packages, because not all packages are going to come in the form of source code.
So portage is a much more complicated project than apt. Therefore, the easier way of going about what you're talking about is finding an easy way to address any problems with portage until it works as well as apt does.
Trouble is, though, that portage was written in a rather slow bytecode-oriented language, and it's built up quite a bit of cruft. Its a system utility; it should be written in C.
So while we're designing the perfect system, probably the fastest way to get there is to rewrite something that uses a lot of the same algorithms as portage, but is optimized and addresses any common complaints that have arisen. Then we just need to start maintaining a compiled code repository for it.
Progress is being made on both the compile code and the optimization fronts. I hope to see great things by next year.
Oh...and to aid in an upgrade path to such a thing, it should probably be able to use apt or rpm repositories and convert the packages therein into its own kind of packages (such a utility already exists to convert CPAN packages - why not others?)
It seems to do very little to protect them from dishonest customers who would try to exploit THEM.
That's right. They're not entitled to the same level of protection as consumers because they make the profits. They're supposed to be able to handle that themselves under almost all conditions.
But if you walk into a Walmart and buy a pair of toasters on a 2 for 1 coupon, then return them one at a time without a receipt for a full refund on each of them -- that is just a plain old fashioned scam. Just because their flawed "customer service policies" let you get away with it doesn't make it a remotely moral thing to do.
This is yet another oversimplification. Perhaps you should only address the instance at hand? Maybe you'll be less likely to do that then. Such a scam is known to be illegal, and the police could indeed become involved. That's not at all like buying something, paying next to nothing for it, and then getting charged for it afterwards. Exploiting a pricing mistake is not fraud.
If walmart were to say, "its a completed sale, its got a $500 sticker on it, its wasn't advertised as less anywhere else in the store the day you bought it, so no refunds; you were clearly appraised of the price at checkout, and you even signed your credit card slip" you'd probably throw a SCREAMING FIT.
Why is it ok to screw amazon, but a dirty sin if you get screwed?
IHMO this is a straw man argument. I am not a store, and I think that this changes things. Retail establishments are held to a higher standard than individuals because they're the professionals. They take the risks of having a consumer business, but in exchange they're the ones making the money. They should make fewer mistakes because they get more practice, and any typos that result in free stuff are the cost of doing business badly.
If I buy some piece of junk from Hong Kong of of some guy on e-bay, I'm taking my chances. That guy makes a lot less money off of me because of this. If I end up with stuff that doesn't work, then I eat those costs. If I buy it at WalMart, I'm doing so because it has WalMart's good name, the BBB, and the United States government (who are allowing it to incorporate) behind it to ensure that it's doing everything it can to conduct itself well.
If I buy something from WalMart, then my problem is their problem, and their problem is their problem. I expect exactly the same from Amazon. Out of the goodness of my heart, I may choose to make it my problem, but that's my moral prerogative. I expect them to always be willing to deal with their mistakes.
My definition of "know" is based around being able to do the best practice approach to the use of the language, and having written at least one non-toy app in it. For compiled languages that means something around 10000 lines. For interpreted languages it's closer to 3000...less for some, more for others. For description languages, such as XSLT or VHDL, it's more like 100.:)
If your definition is stricter than that, fine. For my job I use Java, C#, Perl, HTML, Javascript, XSLT, VB, a few variants of SQL, (including the Hibernate one, which is pretty much a language unto itself) and a few minor miniature proprietary scripting languages, and I use all of them on a weekly basis and have for several years.
I grew up programming in Basic (learned Apple's, Commodore 64, TI-85) and that silly LOGO language, took four courses over two years that used Pascal, and wrote my thesis in Latex about my work with C++ and VHDL (after spending two years writing all my research work in C++). Then I spent three years working mostly with Matlab and C.
How many of those would you count? That's not even counting the other ones that I've only written stuff in for fun - like LISP, python, ruby, or PIC Assembly, or the template languages I use regularly like UJAC, Freemarker, PDF::Template, HTML::Template, and Velocity.
Re:Opposite way of thinking?
on
PHP 5 in Practice
·
· Score: 3, Insightful
I take it you're a computer scientist.:)
As someone who knows fourteen programming languages, but also has a degree in CS with a minor in math, the reason for the that practice among software developers is not because they don't know how (although, admittedly, I've met a few who probably couldn't write low level stuff for themselves), but because there's a best practice way of doing a lot of stuff in any given environment.
In other words, you try to do things the same way that most people who use the language do it so that your code can be used by other people, and so that you can use other people's code to help you do it. Otherwise you have to reinvent the wheel a lot.
Programming languages are a math unto themselves. It's pattern recognition, and "speaking" the languages is the crux of most of it. A CS program should teach you how to learn them quickly. The seasoned programmer, whether CS grad or experienced developer, should be the ability to think in different languages by understanding the differences in their patterns.
But, just for fun (since I can't remember), which law of thermodynamics does the production of power violate?
I'm looking at 'em, but I can't find a law of conservation of power. I'm sure that's the one you meant, though, right.
Hmm... I guess I'm going to have to walk to work tomorrow. My car is currently sitting in the driveway producing no power (since none of it's components are doing any work at all), and thanks to xaxxon's newly discovered law of conservation of power, that means it isn't going to be producing power in the future, since it's previous means of doing so was by using stored energy rather than any form of power.
Incidentally, I think I'm going to have to cut this post short. I imagine it's not going to be too long before somebody realizes that computers have nonconstant power systems and it stops working. I just pray nobody gets around to doing the same to all life on this planet.
In the news report on the subject (linked elsewhere here) , it said that she can no longer fully close her eyes. So that's probably the reason for that.
Similarly, the cost of motor cars has come down since the Model-T Ford - they should cost $1.5 million each (based on inflation - discounting better performance these days)
Actually, from my grandparents and their friends I get the idea that cars are far less affordable than they used to be. People used to buy cars outright when they broke down. Of course, they used to be boxes for moving people from one place to another.
Today they're more like portable rooms filled with fun things to do.
Re:Nine women cannot have one baby in one month
on
Why Software is Hard
·
· Score: 1
That's 'cause nobody's figured out how to parallelize the construction process.
The same cannot be said about programming. (Incidentally, if anyone knows how to parallelize the construction of babies, would you care to share?)
Most cooking projects don't take more than 10 man-hours, but pretty much every programming project does. And, furthermore, mostly when the chef makes a mistake it's obvious to her.
Neither condition hold for programming. It's for this reason that I think that, in general, *two* programmers can program faster than one. At least, me and my partner can program code that's more bug-free together than we can when we program separate projects, and that makes a difference. If the project is sufficiently large - i.e. takes longer than about 10 hours, the cost of communication between two people is less than the cost of switching.:)
While we're at it, I think that there's another misconceptions in this interview.
programmers are programmers because they like to code -- given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter
Two of the five developers at my little software company are programmers because they like to figure things out. So we almost always figure someone else's code out before we do anything ourselves. There are varying degrees of this in a lot of the developers we've got there. I would say that none of us will write anything ourselves unless it saves us a considerable period of time.
But even more, if you had a relative who was always wondering, "What is it that you do all day?" you could hand my book to that relative and say, This is what my work is really like.
No. I couldn't. My experience as a developer is nothing like what he's described. And he didn't talk about the phenomenon of unknowns that I've noticed - for every project I do, if I estimate how long the known things will take, dealing with unknowns will generally take 60% longer (so multiple time estimates by 3 is generally correct). He didn't talk at all about testing.
Almost everything he talked about are things that I thought would be true when I started but that have ended up more or less untrue. Discipline coding makes a difference. Automated unit testing catches most problems, and regression testing finds almost all the rest, and not everybody does these things.
es, it's simple, but maybe Microsoft just doesn't like families. Or it's a big conspiracy to lure all the people with false claims and hacked keys to come in and "get a new one".
Or maybe they just don't know how to handle problems like always.
"Any sufficiently advanced incompetence is indistinguishable from malice."
Slashdot Mirror
TIFF is a huge mess. Let's face it; it's a gigantic cockup. Anyone can write TIFF files, but they're nearly impossible to "read" in the sense that a user is going to expect: if I say that my application will "read TIFFs," they're going to expect that anything with a TIF extension is going to get read. And that's almost never the case; you can pack just too much stuff into the container.
I fail to see how DNG is going to be any different from this. They've already said that there are going to be multiple versions of it as it evolves, and it is already a limited subset of tiff - which, by the way, isn't terribly efficient.
We need to have something that does at least as well as zip for lossless stuff, (that's probably okay with DNG since Adobe is trying to get it use for cameras), and wavelet transforms for lossy stuff.
Personally, I'd prefer that this means that we standardize on two formats.
You may be thinking, "but we have jpeg for lossy." Why isn't this enough? The answer is maps. Those suckers are huge, but you want to put them on tiny devices for navigating. Further, you want it to be easy to zoom in to really small resolutions without seeing horrible artifacts. DWT does this much, much better than DCT.
You like DNG for one? Works for me. Existing TIFF readers can be retrofitted to read DNG. I suspect, though, that this format will get about as much play time as PNG gets now. Given a JP2 and a DNG that's 95% larger, but both look almost identical, which do you think people will want to use in their portable devices?
Right now I'm still thinking that jpeg2000 is good for general purpose use (when you care about storage space more than processing power - which is almost all of the time). It's already got support in a lot of apps and is well understood. I imagine that as images get bigger, the desire to use this space-saving format, or another one that uses DWT will probably creep in.
it wouldn't eat into their "crapware subsidy"
Actually it would. Microsoft Office Crapware Edition comes loaded on most of prebuilt computers. It's a trial use version of Office.
I bet Microsoft is doing something for them for the privilege of putting that thing on there. I bet that Microsoft wouldn't be willing to do whatever that is if something better than Office Crapware was also installed.
Insightful, but only half right. Same for the original poster and the GP.
The puncher doesn't fly backwards because his fist is gradually accellerated over a period of time (say 0.3 seconds). The Newtonian reaction to this is a backwards-pushing force that is small enough to be countered by the friction between his feet and the floor.
That has nothing to do with when he actually hits, however. The mass that is being pushed forward is a small one - the mass of his arm. Remember, Force=Mass*Acceleration. You can accelerate that thing pretty fast because the mass is small, not because you're doing it gradually. You can't punch hard enough to throw the rest of you backward and rip your arm off even if you're accelerating it faster than gravity.
When you actually connect, you put *more force* into the blow while you're hitting.
Entry level boards from both Xilinx and Altera run about $50. Personally, I think it's worth it to spring for the $200 models since you get all kinds of useful things already on it (like RAM), but the $50 ones are out there. Here's some examples.
A $50 FPGA can be made to work as a 256 color VGA driver (or any size lcd controller you like), and you can easily get it to accept PS/2 input from a keyboard.
Then you pick your poison for processors, coprocessors, etc - as long as it fits on the FPGA.
You have lots of options.
user can type away in a standard TEXTAREA field and know when some predefined text area in a PDF document is full... ...but the ONLY browser specific problem I ran into was...
c hEvent,getElementsByTagName,childNodes,parent
No offense, but that means that you don't know much (or forgot about) the major incompatibilities between browsers. There's a great, sleeping dragon that you just barely skirted.
I assume you're attaching an "onkeypress" or "onchange" event to the textarea. That would be the logical approach to that.
Lets say that you liked your code and decided to implement it on another form, only this form is written to validate the entire form when you finish everything using some clever framework-generated javascript - maybe rails, maybe struts...whatever.
Does your code still work the same in both browsers?
No - because DOM event-compliant browsers and IE both bubble events differently. Fixing these two to work together in one browser won't fix them in the other. You have to have special cases to deal with both varieties. And that ends up being a huge pain if your framework didn't think of this to help ensure that every node with a listener on it gets to actually see its events.
This is the fundamental problem that means that everyone always has to check for cross compatibility. Without events, javascript isn't dynamic. Without events, everything that javascript does can be done either server-side or with straight HTML. Events are the core of javascript, and they work differently depending on the browser.
The is only the biggest problem. There are others. Most notably, there are some parts of IE that won't even accept events. You have to keep in mind which parts those are and basically not use them in Mozilla at all if you want your script to work everywhere.
And now something completely different...I've identified a real problem. Now I'd like to address what I see as a nonproblem.
Stuff that relates to the DOM often differ from browser to browser while the core language does not.
Where exactly are you getting this? IE accepts all of the node addressing features of the DOM. While the event framework isn't supported (and it certainly isn't core to the functionality of DOM; it was tacked on afterward), anything at all that can get events through other means can get them through the DOM.
As an example, here are the crucial DOM functions that I use that work in IE the same way that they do in Mozilla (a lot of these will work with any node object from the DOM; some are restricted to the global variable "document"):
getElementByID,getElementsByName,attachEvent,deta
That covers the vast majority of scripts out there that use the DOM. Because IE has it's own special way of addressing things, you're more likely to cover everybody if you *do* use the DOM rather than not, since IE supports those things too. Which functions are you referring to that it doesn't support?
It's not as cut and dried as all that. They should already have java 5 packages, and stuff that uses them.
Well, this is the reference implementation of such a package. Further, since its all done according to a VM spec, it mostly just works.
Given all that, the amount of testing needed shouldn't be as much as it is for other packages. I don't care about waiting for the latest unstable release of some package put out by one guy in his basement, but this isn't that. It's a HUGE player with its own testing department.
My distro doesn't focus on bleeding edge. I don't use bleeding edge. They spent a whole *year* in Gentoo getting ready for a smooth Java 5 migration. (It *used* to be bleeding edge, but it hasn't been for about five years).
I expect that no matter what distro it is, there should be a level of pragmatism. It shouldn't take anybody as long as its been to test everything to their satisfaction. The fact that it does means there's more red tape than their needs to be.
I see a lot of myopia on these threads on this subject; this isn't a complaint trying to get some free stuff/getting it faster/getting people to do stuff for me. It's an observation that Debian isn't doing well compared to other distros. There's something wrong with it if it takes hundreds of times as long to mark something as stable as most of the rest of the distros take.
Twice as long, maybe - maybe even four times as long. But I think they're pushing the length of time these things take to the point that what they're doing is something besides testing. Maybe they don't have the people for real tests, or maybe they have a lot of red tape. I don't know.
I'd just rather not use a distro with so little impetus when there are ones that other people are working on more diligently.
Entitlement? Okay, sure. Yeah. I want Debian to do me the "huge freaking favor" of downloading the jdk and keeping track of what's in the file system.
How long does that take? I know it'd take me about five minutes (and it *shouldn't* take more for any reasonable package management system)...what is that amortized over all the users of Debian? I'm sure it comes to less than a second each. I think you may be exaggerating how much of a favor it would be for a Debian user - though I am not one.
This has nothing to do with what I want. I don't care one way or the other what Debian does.
If I did I'd probably be involved in it.
Well...that's not quite true. Because I know that I have to either use unstable packages or deal with not getting stable stuff until way later, I have decided not to have anything to do with Debian. Otherwise I might be using it now. If Debian was the only choice, of course, I'd use it and be thankful for it.
But it's not, is it?
Why wasn't the work done before it was launched so that it was immediately usable?
I got the new JDK a few days afterwards from Gentoo, and I think it was ready a few days before I got it.
You don't think the fact that people naturally think imperatively and not functionally has no bearing on the situation?
When it's the difference between lisp, which was marginally easier to develop with once you understood it, or cobol, which was easier to understand, but harder to develop with once you knew it, which do you think people would choose?
Cobol more than nine times out of ten...and with the increase in coders, there was an increase in available code. Pathways to solve common problems were made and LISP's natural ease-of-devel benefit was taken away.
If I can make a prediction about current techs, I would say that this is why things like ActiveRecord are going to beat out complex ORMs like Hibernate. There are a lot of other things with that same possibility.
SOAP versus XML-RPC, Oracle versus every other database system on the planet, and Java versus high level scripting languages that can also run on VMs.
Of course, with mitigating factors like throwing money at the problems, I could end up wrong about these. But I think that's the way that things are currently progressing: when the margin of difference is small enough, the initial learning curve makes all the difference in the world.
The best best case sort you can get is n. An optimal algorithm would always hit that.
What it has is the optimal worst case, which is not the same thing at all.
When picking a sorting algorithm, you have to consider the best, worse, and average cases, and specifically how it deals with the kind of dataset you have.
Mergesort's best, worst, and average cases are all the same - nLog(n)
It's sort of like a compromise. It's not really fast at any particular case, but, then again, it's never bad.
If your data is perfectly random, or you know nothing about it, then merge sort is your algorithm.
However, on semi-sorted data, quicksort performs better or worse than merge sort. Better if it's almost sorted in the correct order, (O(n) if it is sorted in the right order), or worse if it's sorted mostly in reverse order O(n^2) if entirely in reverse order.
Most data that is created by humans is partially sorted (i.e. in human data entry cases)...so there are many places that quicksort is usually a better choice. However, given any unknown set sample, there is a much higher likelihood that the set will be mostly random - meaning on average when considering all possible sets, mergesort performs better.
These are the two extremes in the sorting world - quicksort has best best case, but the worst worst case, while merge sort has the best worst case, and the worst best case.
All other sorting algorithms that are considered efficient fall between these two extremes and take advantage of some piece of knowledge about the data (keep in mind that sorting algorithms in general *don't* distinguish between in-place and not in-place. This is almost universally a trivial detail that doesn't effect the order of the algorithm) that lets you do better than O(nLog(n)) on that specific kind of data.
It always seems strange to me that people learn what these two algorithms are without learning how they define the boundaries of the solution space. If you don't know what they're for then what's the point of learning more than one at all then?
Read better. I qualified the point where perl is useful. I'll elaborate anyway.
Unlike heroin and a defective lighter, perl is useful to me and to other developers for throw away code (i.e. stuff you're only going to use once), for small projects, and for heavily QAed coding.
Any of these approaches do a good job of guaranteeing that you won't have any problems with sloppiness.
I would go so far as to saying that in the first two cases - small projects and throw away code are both very good places to use perl. You get your results much faster than if you have to fit things into another language.
Perl makes a very good shell language. It's also good as a configuration language and a text transformation language, specifically because all of these jobs are small and often throw-away.
These are just a few things that I can think of off of the top of my head.
You're not looking at it right.
KISS is hard. Very hard. It's different in different places. Sometimes keeping it simple means writing less code. Sometimes it means creating a new sub-language that better describes your problem.
In perl, you can change the nature of the language itself. *Everything* can be changed. The idea is that if there is more than one way to do it, then you can do it the simplest way for whatever definition of simple is required.
Maintaining consistency is up to the developer himself. Obviously, those tempted to succumb to the lure of sloppiness (which, unfortunately, in my experience, is every perl programmer I've ever met including myself) shouldn't use perl for really big projects.
You can't blame the language for giving you that freedom, though.
Perl is where it is because you don't have to change the way that you think in order to program in it. Perl will change how it works to match how you think, which makes it more convenient than almost any other language.
That particular behavior is what makes it possible to have so many perl modules in existane, which in turn is responsible for the popularity. It's also why about half of those modules have bugs so horrible that they're unusable. It's certainly a tradeoff.
Cool? Warm? Soft?
There's no reason for this. We use these words to describe things that we don't have a good way of describing other ways (like sound...the only word that means "having more undertones than the characteristic tone of the sound producer" is "warm.")
But there are more words for light than there are for any other sense because our brains process vision better than we process anything else. There's no need to use touch words to describe light.
So...what does what you said just mean using visual adjectives?
I feel like you're approaching this from the wrong side.
IMHO, the best binary installer is apt. It's got the most features that work.
Similarly, the best source installer is Portage. So what I think we really need is something that works a bit like both.
Bearing that in mind, you must also consider that portage was basically designed as an improvement of ports and apt. It's got a lot of the same features. Here's the deal, though: a source installer needs to be able to do everything that a binary installer can, and it must also be able to do a lot more. It needs to check for variables dependencies, and handle package compile options, downloading code from repositories, and sometimes dynamic dependency resolution. Of course, it also has to handle exactly the same things that apt does - installing binary packages, because not all packages are going to come in the form of source code.
So portage is a much more complicated project than apt. Therefore, the easier way of going about what you're talking about is finding an easy way to address any problems with portage until it works as well as apt does.
Trouble is, though, that portage was written in a rather slow bytecode-oriented language, and it's built up quite a bit of cruft. Its a system utility; it should be written in C.
So while we're designing the perfect system, probably the fastest way to get there is to rewrite something that uses a lot of the same algorithms as portage, but is optimized and addresses any common complaints that have arisen. Then we just need to start maintaining a compiled code repository for it.
Progress is being made on both the compile code and the optimization fronts. I hope to see great things by next year.
Oh...and to aid in an upgrade path to such a thing, it should probably be able to use apt or rpm repositories and convert the packages therein into its own kind of packages (such a utility already exists to convert CPAN packages - why not others?)
It seems to do very little to protect them from dishonest customers who would try to exploit THEM.
That's right. They're not entitled to the same level of protection as consumers because they make the profits. They're supposed to be able to handle that themselves under almost all conditions.
But if you walk into a Walmart and buy a pair of toasters on a 2 for 1 coupon, then return them one at a time without a receipt for a full refund on each of them -- that is just a plain old fashioned scam. Just because their flawed "customer service policies" let you get away with it doesn't make it a remotely moral thing to do.
This is yet another oversimplification. Perhaps you should only address the instance at hand? Maybe you'll be less likely to do that then. Such a scam is known to be illegal, and the police could indeed become involved. That's not at all like buying something, paying next to nothing for it, and then getting charged for it afterwards. Exploiting a pricing mistake is not fraud.
If walmart were to say, "its a completed sale, its got a $500 sticker on it, its wasn't advertised as less anywhere else in the store the day you bought it, so no refunds; you were clearly appraised of the price at checkout, and you even signed your credit card slip" you'd probably throw a SCREAMING FIT.
Why is it ok to screw amazon, but a dirty sin if you get screwed?
IHMO this is a straw man argument. I am not a store, and I think that this changes things.
Retail establishments are held to a higher standard than individuals because they're the professionals. They take the risks of having a consumer business, but in exchange they're the ones making the money. They should make fewer mistakes because they get more practice, and any typos that result in free stuff are the cost of doing business badly.
If I buy some piece of junk from Hong Kong of of some guy on e-bay, I'm taking my chances. That guy makes a lot less money off of me because of this. If I end up with stuff that doesn't work, then I eat those costs. If I buy it at WalMart, I'm doing so because it has WalMart's good name, the BBB, and the United States government (who are allowing it to incorporate) behind it to ensure that it's doing everything it can to conduct itself well.
If I buy something from WalMart, then my problem is their problem, and their problem is their problem. I expect exactly the same from Amazon. Out of the goodness of my heart, I may choose to make it my problem, but that's my moral prerogative. I expect them to always be willing to deal with their mistakes.
My definition of "know" is based around being able to do the best practice approach to the use of the language, and having written at least one non-toy app in it. For compiled languages that means something around 10000 lines. For interpreted languages it's closer to 3000...less for some, more for others. :)
For description languages, such as XSLT or VHDL, it's more like 100.
If your definition is stricter than that, fine. For my job I use Java, C#, Perl, HTML, Javascript, XSLT, VB, a few variants of SQL, (including the Hibernate one, which is pretty much a language unto itself) and a few minor miniature proprietary scripting languages, and I use all of them on a weekly basis and have for several years.
I grew up programming in Basic (learned Apple's, Commodore 64, TI-85) and that silly LOGO language, took four courses over two years that used Pascal, and wrote my thesis in Latex about my work with C++ and VHDL (after spending two years writing all my research work in C++). Then I spent three years working mostly with Matlab and C.
How many of those would you count?
That's not even counting the other ones that I've only written stuff in for fun - like LISP, python, ruby, or PIC Assembly, or the template languages I use regularly like UJAC, Freemarker, PDF::Template, HTML::Template, and Velocity.
I take it you're a computer scientist. :)
As someone who knows fourteen programming languages, but also has a degree in CS with a minor in math, the reason for the that practice among software developers is not because they don't know how (although, admittedly, I've met a few who probably couldn't write low level stuff for themselves), but because there's a best practice way of doing a lot of stuff in any given environment.
In other words, you try to do things the same way that most people who use the language do it so that your code can be used by other people, and so that you can use other people's code to help you do it. Otherwise you have to reinvent the wheel a lot.
Programming languages are a math unto themselves. It's pattern recognition, and "speaking" the languages is the crux of most of it. A CS program should teach you how to learn them quickly. The seasoned programmer, whether CS grad or experienced developer, should be the ability to think in different languages by understanding the differences in their patterns.
Yeah. Really silly, huh?
But, just for fun (since I can't remember), which law of thermodynamics does the production of power violate?
I'm looking at 'em, but I can't find a law of conservation of power. I'm sure that's the one you meant, though, right.
Hmm... I guess I'm going to have to walk to work tomorrow. My car is currently sitting in the driveway producing no power (since none of it's components are doing any work at all), and thanks to xaxxon's newly discovered law of conservation of power, that means it isn't going to be producing power in the future, since it's previous means of doing so was by using stored energy rather than any form of power.
Incidentally, I think I'm going to have to cut this post short. I imagine it's not going to be too long before somebody realizes that computers have nonconstant power systems and it stops working. I just pray nobody gets around to doing the same to all life on this planet.
In the news report on the subject (linked elsewhere here) , it said that she can no longer fully close her eyes. So that's probably the reason for that.
Similarly, the cost of motor cars has come down since the Model-T Ford - they should cost $1.5 million each (based on inflation - discounting better performance these days)
Actually, from my grandparents and their friends I get the idea that cars are far less affordable than they used to be.
People used to buy cars outright when they broke down. Of course, they used to be boxes for moving people from one place to another.
Today they're more like portable rooms filled with fun things to do.
That's 'cause nobody's figured out how to parallelize the construction process.
The same cannot be said about programming. (Incidentally, if anyone knows how to parallelize the construction of babies, would you care to share?)
Most cooking projects don't take more than 10 man-hours, but pretty much every programming project does. And, furthermore, mostly when the chef makes a mistake it's obvious to her.
:)
Neither condition hold for programming. It's for this reason that I think that, in general, *two* programmers can program faster than one. At least, me and my partner can program code that's more bug-free together than we can when we program separate projects, and that makes a difference. If the project is sufficiently large - i.e. takes longer than about 10 hours, the cost of communication between two people is less than the cost of switching.
While we're at it, I think that there's another misconceptions in this interview.
programmers are programmers because they like to code -- given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter
Two of the five developers at my little software company are programmers because they like to figure things out. So we almost always figure someone else's code out before we do anything ourselves. There are varying degrees of this in a lot of the developers we've got there. I would say that none of us will write anything ourselves unless it saves us a considerable period of time.
But even more, if you had a relative who was always wondering, "What is it that you do all day?" you could hand my book to that relative and say, This is what my work is really like.
No. I couldn't. My experience as a developer is nothing like what he's described. And he didn't talk about the phenomenon of unknowns that I've noticed - for every project I do, if I estimate how long the known things will take, dealing with unknowns will generally take 60% longer (so multiple time estimates by 3 is generally correct). He didn't talk at all about testing.
Almost everything he talked about are things that I thought would be true when I started but that have ended up more or less untrue. Discipline coding makes a difference. Automated unit testing catches most problems, and regression testing finds almost all the rest, and not everybody does these things.
es, it's simple, but maybe Microsoft just doesn't like families. Or it's a big conspiracy to lure all the people with false claims and hacked keys to come in and "get a new one".
Or maybe they just don't know how to handle problems like always.
"Any sufficiently advanced incompetence is indistinguishable from malice."