Java has things like static type checking -- to the point where you must explicitly declare what exceptions you might run into.
Unless you're dealing with exceptions that subclass RuntimeException -- those don't need to be declared in a method signature, because they're unchecked exceptions. If you are trapping a condition that's truly exceptional and might not be recoverable, an unchecked exception makes sense (and saves you from a lot of try/catch blocks in your code).
But then, managers like to see Java as a good thing precisely because it's so limiting. It forces everything to some level of mediocrity and sameness, meaning horrible programmers are just slightly bad because Java keeps them from shooting themselves in the foot. It also means you can hire a team of horrible programmers, and replace any one of them with another at any time, and the project will continue moving forward. And it's great for programmers, because they can look busy all day writing interfaces, typing ridiculously long method declarations, and dealing with the complexities and limitations of things like single inheritance, without having to get much actual work done (or do much thinking).
Actually, I've worked with a number of horrible and mediocre programmers (some of them ex-Motorola people), and I can tell you definitively that Java does not save them from themselves. It doesn't even do a good job of protecting the good programmers from dealing with the messes made by bad programmers. Judging from the rest of what you wrote, it sounds like an academic laundry list of complaints about Java, and not a set of complaints written by someone who's ever had to write a nontrivial piece of code in Java.
But what people are finding out is, flexibility like Perl's is really useful. Look at Ruby. The syntax looks OK on the surface, but get into even marginally complex programs and it can look as ugly as Perl. But it's also amazingly flexible, quick to code in, and makes a bright programmer into a brilliant programmer -- whereas Java will take your bright programmers and beat them down into codemonkeys.
Totally unsubstantiated posturing. Also totally ignores one of the real problems with Perl (and even Ruby, to a lesser extent) -- code maintainability. Production Perl code I've seen is almost uniformly hairy and impossible to maintain -- sometimes even by the person who wrote it originally. Java enforces standards and conventions which improve productivity and maintainability. When you consider that 80% of the cost of any software project is in the maintenance, that's a major factor. That's the real reason why people who manage IT like Java and C#, not because they're trying to oppress you.
Viewed that way, Perl and Ruby become great languages to do prototyping, or to do quick, one-off programs that accomplish something that you wouldn't want to do in some lesser shell scripting language. The flexibility you cite becomes an advantage in these cases. But I would not want to revisit Perl code for a utility that's going to be in use for any length of time; hence, I would say Ruby is the superior tool in this instance. I still wouldn't want to use either for any kind of substantial enterprise application development.
Before templates, I was actually forced to typecast to and from Object...
They're called "generics" in Java. They also don't work quite the same way as C++ templates. In fact, Java generics basically take care of the casting behind the scenes for you; they just help insure that everything is typesafe at compile time, so you don't have to deal with ClassCastExceptions at runtime.
This is flatly retarded, by the way -- if Java can give me a compile-time error that my method didn't declare a particular exception, why can't I simply omit all such declarations and let the compiler add them back in?
Well, I know laziness is considered one of the car
You can't make a patent "public domain," but you can dedicate a patent, which effectively means that anyone can use the patent without paying licensing fees. It also guarantees that nobody else can (legally) claim a patent covering the same invention.
Actually, IE 5.x on Mac OS X had full PNG alpha channel support, with compositing and everything. It was one of the browsers with which you could showcase pages like this one.
I already addressed this issue in a sibling comment to yours, but I figured I'd address this specific point here (as I'm one of the authors of the PNG spec).
PNG was only ever intended to be a format to store image data, not animation data. The use of GIF animations wasn't very widespread when the GIF LZW patent crisis prompted a group of developers to work on the PNG specification. MNG is the sister format, is specifically intended to cover animation applications, and builds upon the PNG specification. (Without glancing at the specs, I recall that a PNG is more-or-less a valid MNG file, but not the other way around -- MNG is therefore a superset of PNG. Although I worked on the PNG spec, I have no real connection to the MNG folks.)
APNG was an effort that originated outside the PNG/MNG group, and it failed to be ratified as an extension to PNG -- mainly because it goes contrary to the mission of PNG, which is to be a standard for storing single images. The rejection of the APNG proposal happened earlier this year, according to the Wikipedia article. Apparently undaunted, the Mozilla folks stuck APNG support into Firefox, but who knows if it'll stay there. The format extensions for APNG are officially unsupported and non-standard, making Firefox the lone holdout on this. Why they couldn't just support MNG is anyone's guess.
Basically, by the time animated GIF became a serious issue, the PNG spec was very close to frozen, and the core spec authors and library developers successfully argued that PNG should be kept solely for image storage. (During PNG development, a THMB chunk was proposed to store a thumbnail version of the full image. This was killed for similar reasons to the APNG extensions.) I tend to agree that stuffing animation features into a file format intended for still images makes the decoder more complicated, and doesn't offer a very optimal solution for animation. The whole notion of animated GIFs never sat well with me either, even though they proved to be popular with HTML jockeys.
Further reading seems to indicate that Mozilla's developers had MNG support, but yanked it in favor of APNG support. I can only guess the motivations, but sounds to me as though they wanted to blaze their own path for political/personal reasons, not necessarily sound technical reasons.
I'm one of the co-authors of the PNG spec, so I will give my answers to your questions. I can't claim to speak for the other PNG spec authors.
Where does PNG fit into the [paradigm]? I mean, I know it's got more advanced alpha transparency than gif, and I think that it's based on plain ol' bitmaps as opposed to compression, so it seems like a strict successor to GIF...
PNG was always intended to replace GIF and be a "better GIF than GIF." PNG is also a more-than-adequate replacement for most common TIFF variants, because you can do almost everything that TIFF can do, but with less complexity (fewer choices for implementation, simpler format, and no optional format features you can't live without that some readers may choose to ignore) and less ambiguity in the spec. The less ambiguity bit is important, since the TIFF spec's ambiguity is one of the main reasons that TIFF files written by one application may not be readable by another application -- even if both apps support the same TIFF extensions.
PNG has compression -- it uses deflate (LZ77 + Huffman coding) instead of GIF's formerly-patent-encumbered LZW algorithm. The key here is lossless compression, so unlike bog-standard JPEG, PNG images are great for archiving exact image data. Radiologists like the fact that PNG can store grayscale images with 16-bit-per-pixel accuracy, in complete image fidelity.
Yes, PNG has better alpha channel support than GIF (although it has a special palette-based transparency feature similar to GIF89's transparency, mainly to ease the transition from GIF to PNG). It also has a better interlacing scheme, for progressive rendering of images when your data pipe is constrained. Set-top-box developers like this feature.
Where PNG fails with high def photos and the like is the lack of floating point representation of pixel data, which limits the kind of High Dynamic Range stuff you can do with it. PNG has chunk types which can contain many of the kinds of meta-data that you would care about for digital photography and scanned artwork, but much of the reader code out there does nothing with this meta-data.
However, gif still has some legs up on it, namely ubiquity and the fact that animated PNGs support doesn't seem to be remotely common.
Actually, PNG doesn't support animation at all. The animated sister format is MNG. Animated GIFs are kind of a poor animation format anyway, but they're great for small-size effects on web pages. MNG support in browsers is non-existent, so this has paradoxically limited PNG's uptake (and made GIF more difficult to kill).
It didn't help Be that Metrowerks pretty much abandoned development on the developer tools for BeOS, and had no intention of even telling Be, Inc., that the effort was being quietly halted. I know because I was the last hire for the "Be Hive," when Metrowerks was still headquartered in Austin, TX. I was going to relocate from Phoenix to Austin for this job, and then one day my boss called me at my house in Phoenix (where I was working while trying to market my house so I could relocate) to let me know what was going on.
At that point, I was offered a chance to switch to one of Metrowerks' other divisions, but I declined, since I really had taken the job because of the BeOS development work. (Actually, I gave my boss a really inflated estimate for how long it would take me to sell my house and move, and that had the same general effect. Kind of like saying, "Gee, my motivation to move has just been destroyed.")
What pissed me off is that the company had no plan or (apparent) intention of warning Be or handing off development in a coherent, sensible way. Fortunately, Be found out through the grapevine, but by that point, they'd lost a major ally.
Later on, I ran into Dominic Giampolo at Comdex; I had seen him a couple times at the Metrowerks office in Austin, so we exchanged warm greetings after I reminded him of who I was. Dominic told me I should say hi to Jean Louis, but warned me to downplay the Metrowerks connection because feelings were still a bit raw over that whole incident.
Had Be been given a fair shake, there's no telling what they could have done. I think BeOS would have been a great PDA/smartphone OS, and before I left Metrowerks, I saw evidence in the Be header files that they had porting efforts underway for CPU architectures like the Hitachi SH-3/4 (which were popular chips for PDAs at the time).
THX is mostly marketing these days, true, but you'd be amazed at how much it costs to get THX certification for a piece of home theater hardware. (I have a high current power amp which is THX certified, and although it's an impressive piece of hardware, there's little about the design that specifically was required by THX -- basically, the amp vastly exceeded the minimum power and distortion requirements, and the manufacturer put a couple of trimpots on the inputs so you could do careful level adjustment.)
I suspect much of the price differential between the Series 3 and the "Lite" is due to the omission of THX certification. The removal of the OLED display and the switch to some more integrated chips (and a cheaper mainboard) all help keep manufacturing cost down, but those changes by themselves aren't enough to explain the huge price drop.
Even at $500, instead of $800, I still can't afford Tivo HD.
Actually, it looks like the Slashdot summary got it wrong; if you read the Ars article referenced in the summary, this new Series 3 Lite is actually $300, not $500 (as implied by the summary). It's not $300 cheaper, it's $300, period. This has been echoed at other websites, although I'm still waiting on official announcement of the product before I'll believe any pricing information.
I think the confusion stems from the comparison table in Ars' article, which gives prices for both the Series 3 and the Series 3 Lite, and notes that although the Series 3 has an MSRP of about $800, it can be had for about $300 cheaper due to rebates, sales, and other promotions.
no surprise a moron like you missed the use of Nietszche's "Eternal Recurrance" and other extremely high brow concepts in LEXX... dumbass.
(Emphasis added by me.) Look, if you're going to berate someone for being an idiot, at least try to make yourself look a little more intelligent by spelling "recurrence" correctly, and using some basic capitalization and punctuation. Bonus points if you can tell the difference between stupidity and ignorance, since the issue you're taking task with could just as easily be ascribed to ignorance as to stupidity. (Since you don't know which is the case, it's kind of rude to assume the worst case about someone you've probably never met and know nothing about.)
Actually, isn't it the other way around? Mitochondria use oxygen to break down ATP into ADP, thereby releasing energy that the cell uses for work?
No, the mitochondria use oxygen and glucose (well, the byproducts of glycolysis) to manufacture ATP using the Krebs cycle. Please see the Wikipedia article on Mitochondria for more info.
Really, after you watch a movie a few times, its not much more use to you unless you have problems with your brain which should remain outside the scope of legislation.
Unless you're one of those silly people who likes watching a movie over and over again... like my aunt, who watches It's a Wonderful Life every Christmas -- and even bought me a movie trivia game solely about that movie one holiday, yikes!
But yeah, thanks for implying that fans who re-watch movies regularly are somehow brain damaged. I suppose you think people who re-read their favorite books are also similarly mentally challenged... even though many published authors will read and re-read the works of other writers to get ideas and to try and infuse some of the other writer's style into their own. Yeah, they must all be brain damaged too.
Whoops, scratch what I said about QAM. After more careful reading, it looks as though EIT is available for cable systems in the U.S., although the article cited doesn't address the issue of encrypted QAM (which most open hardware and software can't decrypt, making the QAM capabilities of most HD tuner cards limited at best). So even though EIT might be technically available for digital cable users in the U.S., it might not be practically accessible to MythTV. And there are no guarantees for how far in the future scheduling data will be provided.
Excellent link. However, using EIT has at least one drawback:
Unlike DVB systems, an EIT in ATSC covers a limited time span. [...] It's possible to transmit up to 128 EIT tables for any virtual channel, but it's very rare that so many are transmitted - terrestrial systems have to transmit EITs covering at least the current time slot and the next three time slots.
So at least in the U.S., the EIT would be of limited utility to MythTV users, since it is unlikely that one would be able to use this data to schedule multiple days in advance. Also, the article you linked only indicates that EIT is a standard part of ATSC (the terrestrial digital TV broadcast standard), and wouldn't necessarily be present in analog broadcasts (which are going to be around for a little while longer) or in digital cable transmissions (which use QAM here in the U.S.). It's entirely possible that a broadcaster might supply EIT data, and a cable operator might strip it out to save some bandwidth.
I've seen some of the newer LCD HDTVs sold here in the U.S. which have the ability to display program guide data, no doubt culled from available EIT data, but this is really intended to allow viewers to see what's on right now or in the immediate future without resorting to channel flipping. I bought a Sharp Aquos one generation before this feature became standard, so I missed out, but I really don't feel like I'm missing too much because of the described limitations.
I think you mean liter of water instead of milliliter. The later has a mass of 1 g.
No, he meant milliliter. According to the Wikipedia article:
The kilogram was originally defined as one thousand times "the absolute weight of a volume of pure water equal to the cube of the hundredth part of a meter, and at the temperature of melting ice" [...] Also, from the grammar nazi sitting on my shoulder, it's "latter" and not "later." (Dictionary.com's first result when looking up "latter" is actually the entry for "late," and seems to imply that "later" and "latter" are synonymous -- however, in the sense that you meant, this is not the case. The correct sense in this case is "being the second mentioned of two (distinguished from former).")
I suspect that the definition of liter is based on the volume of 1 kg of pure water at standard temperature and pressure, and not the other way around
The liter is a unit of volume, and thus based purely upon length. Furthermore, "standard temperature" and "standard pressure" need to be defined -- and pressure itself is a function of mass and temperature. According to the Wikipedia article, the liter was originally defined as 1 cubic decimeter. In 1901, the unit was redefined as the volume of 1 kg of pure water at approximately 4 degrees C at 1 atmosphere. In 1964, the original definition was reverted to, and therefore the unit was once again defined solely in terms of length.
I thought the whole system revolved around water? 1 cubic centimeter of water is 1 gram, so a cubic decimeter of water is 1 kilogram.
That was the original definition of the gram (1 mL, or 1 cc, of water at 4 degrees C at sea level has a mass of 1 gram), but this definition was later discarded in favor of the platinum-iridium reference mass defined to be 1 kg. I believe the impetus for this change was the imprecision of reproducing the original reference standard, the imprecision of knowing the point of maximum density of liquid water because the density depends partially upon pressure (not just temperature). Pressure itself is partially a function of mass, so there's a circular dependency.
Now all we have to have is that extremely accurate measurement of length and the rest falls into place.
We already have that measurement, based from 1960 until 1983 upon a particular wavelength of the emission spectrum of Krypton, and after 1983 in terms of the speed of light. Originally, the meter was defined in terms of the distance from the equator to either of the Earth's geographic poles (10,000 km), and later in terms of a platinum-iridium reference bar. So our new standard of length is obviously a lot easier to reproduce in the lab since it doesn't rely on an entire planet...
But for the aforementioned reasons, you wouldn't want to use water as your basis for defining mass accurately. Counting discrete things like atoms seems to be a smarter way to go, overall.
Fonts aren't copyrightable, based on numerous court precedents (note: a font is distinct from a typeface: a font is a typeface with a style, weight, size applied)
Not 100% correct. The designs of the characters are not copyrightable in the US, sure, and this is by intent. You can clone any popular typeface by reverse engineering and sell it or give it away, no problem. However, there are two kinds of protection that computer fonts can and do enjoy:
Trademark protection -- a font's name can be trademarked, which is why many Helvetica clones are called anything but Helvetica.
Copyright -- Yes, really. Not on the font design itself, because that's not allowed. What is the copyright on, then? You see, computer software vendors came up with the clever idea of packaging fonts (really typefaces) as software. The idea was pioneered by Adobe with PostScript Type I fonts -- the "font" (typeface) is a set of instructions for stroking and rendering, including hinting for rendering at low resolutions (something that most public domain and freeware fonts don't have).
Currently, the United States is the only country (according to certain partisans, anyway) which does not recognize the copyrightability of non-computer fonts. So your statements are even wrong on the international level. Many countries recognize font designs as artistic works.
Regardless, companies like Adobe and Microsoft can and do claim copyright on PostScript and TrueType fonts. The PostScript case is fairly clear, since PostScript is a complete programming language, and thus such fonts can be copyrighted as software. See also this BoingBoing post which actually cites precedent for Adobe and Emigre Fonts successfully suing another software vendor over computer fonts. In such cases, the rulings talk about "font software programs."
I don't expect that ZFS would be a major announcement from Apple. It's too techie. The keynotes tend to focus on whiz-bang interface features.
Yes, but this is WWDC, not MacWorld. Different audience, different expectations. Jobs' keynotes, even at MacWorld, have in the past delved into technical details that many would consider "too techie," so I'm just not buying that excuse. For the WWDC audience, there's no reason not to talk about ZFS if it's a major new feature, especially considering the tie-in with Sun.
Apparently, one of the editors at InformationWeek (Michael Singer, West Coast Editor) saw several perplexed comments left by readers and added similar commentary to yours, which I thought would be germane:
As to the news, it seems that Croll mispoke [sic] a couple of times when asked about ZFS in Leopard. Despite direct questions about Sun CEO Schwartz's claims that ZFS is there, Croll flatly denied the reports to two of our reporters in a 1:1 interview.
An Apple spokesperson called us Tuesday seeking to clarify Croll's statement. Croll was apparently supposed to indicate that ZFS would be available as a limited option, but not as the default file system."
We are now writing a separate story to note Apple's mis-statement and hopefully to reveal more about how ZFS would work in Leopard.
We'll update you here when that story is live.
Glad to see there's an effort underway to get the facts out to people.
Much of the work of programming is taking an parallel process (i.e. pretty much anything you want a program to do) and translating it into the sequential model used by most programming languages.
Well, that statement makes a gross assumption. Every software developer (programmer/engineer) thinks that their particular domain is representative of what computer programmers do in general. However, if you in fact write software that automates common business tasks, the software is directly analogous to the process it seeks to model and/or replace. Most business tasks are sequential, so procedural single-threaded programming is a perfectly fine model to use.
Yes, for the things that most casual users and computer scientists think are "interesting," there is some inherent level of parallelism that can get pretty high. For a few choice types of tasks (ray tracing, rendering certain fractals), the problem itself is embarrassingly parallel because there is no direct coupling between the solutions of sub-problems. However, at some level you can't decompose your problem any further, and you can extract no more parallelism.
The vast majority of computer software these days is written for businesses. Most of it is not the stuff you see on the shelf at the local computer store, but is written custom to solve a specific business need. Most business processes are inherently serial operations: you perform one step, then you perform another step that depends on the previous step. Occasionally, you get lucky and you discover multiple steps that can be done simultaneously. However, making such processes explicitly parallel might not be the most advantageous move; after all, most modern CPU architectures are adept at out-of-order execution, and can analyze instruction streams to figure out dependencies dynamically. Heck, most modern CPU architectures support multiple in-flight instructions, and allow multiple instructions to complete simultaneously, which extracts parallelism at a very low level.
When I first learnt to program, I remember learning a little about function and then later discovering that they completed synchronously. I was surprised by this, because it just didn't seem to make any sense; a function has a deadline by which it needs to complete (when I use the result), but it can run in the background until then and join with the calling thread.
You can still explicitly use this technique in modern programming languages; Java, for example, has Thread.join() which is used for precisely such situations. However, just because you can do something doesn't mean that you should; there is overhead associated with spawning threads of execution and synchronizing threads when some result is needed. If the computation being performed by a function call is long-lived, then it makes sense to spawn a thread to perform that computation -- assuming that there are sufficient computational resources to truly run that thread concurrently (e.g., another CPU core able to perform that computation). Otherwise, you're burning more computational resources and probably making your code actually slower in the process (due to management overhead). And if you're multitasking on a single CPU core, spawning another thread will almost certainly result in a slower-running program (because you still have all the overhead of managing another thread, but none of the benefit of true hardware-level concurrency).
Most programming tasks are inherently parallel. I can't think of a single piece of code I've written recently that hasn't been a solution to a parallel problem.
The first sentence is really an unsupported conjecture. The second sentence is an attempt to provide anecdotal evidence drawn from your own experiences to support the conjecture in the first. My own life experience is vastly different from yours, but then again, that too is anecdotal evidence; neither your nor my personal experiences are really "proof" o
It used a technical mechanism called SCCS which sounds very similar to this "managed copying."
Close! The mechanism is actually called SCMS, which stands for "Serial Copy Management System." It is the same mechanism used in MiniDisc recorders, and the development of this system is what held up commercial DAT adoption in the United States... which is why today, the only DAT users are professionals and semi-pros.
The obvious solution to your problem is to avoid using special-purpose music CD recording devices, and instead use your computer's CD-ROM drive to do the ripping. Then you can burn as many copies as you like, since computer CD drives totally ignore the "no copy" bit on CDs. SCMS never even comes into play with such systems.
Yeah, some lawyers may argue that such use violates the spirit of the AHRA. Then again, the ability to "Rip-Mix-Burn" has been legally challenged, and found to be a non-infringing fair use in the United States. Some lawyers might claim that ignoring the "no copy" bit on CDs is a DMCA violation, but since computer CD-ROM drives were never obligated to pay attention to this bit (and since computer manufacturers are not obligated to adhere to the AHRA), it's hard to argue that SCMS is any kind of effective technological measure to prevent copying. It's only effective if you stay within the prescribed ecosystem of SCMS -- devices that are primarily designed for recording and playing back digital audio.
What's to stop the DVD publishers from making this "managed copying" available for a while, then using technical means to renege on the terms a few years later?
Absolutely nothing in practice. This is the same way that record labels get away with releasing "copy protected CDs" which don't technically adhere to the Red Book standard. Of course, the licensing authority does have the power to say "You can't sell this disc as XYZ unless it adheres strictly to this specification," and that actually has some force. But most consumers don't even pay attention to the stickers that say "This disc contains copy protection technology and may not play on all CD players," or something similar.
Managed copy was a feature pushed by the device manufacturers and computer companies backing these next generation optical discs. (See this article for more info.) The movie studios never wanted managed copy, but IIRC, HP and some other players pushed the managed copy feature as part of the spec. HD-DVD had mandatory managed copy as a selling point vs. Blu-Ray initially, and the Blu-Ray camp responded by adding managed copy as an option to the Blu-Ray spec, but it's not mandatory, so studios get to pick which discs support it. (HP also tried to push the Blu-Ray group to include iHD, but they refused, since they're pushing BD-J.)
Maybe it's just that you don't know about repression (english translation of the arabic word "islam").
Far be it from me to defend anything about Islam, but... my understanding is that "Islam" means "submission," as in "submission to God's will." Of course, this is unpalatable to me for several reasons (not the least of which is the implication that the relationship between God and Man is one of Master and slave), but "repression" and "submission" are two different things.
Repression is what someone in a position of authority does to you (whether that's secular authority or religious authority; even self-imposed repression is typically carried out in service to someone else's ideology), and submission is something that you do yourself (whether that submission is voluntary or externally forced). Of course, one can lead to the other.
So at worst it would reintroduce a bug you would be able to find and fix later - but who merges without checking it worked?
What if the merges are done by someone who isn't familiar with all the code changes and the expected associated application behaviors? What if there are dozens or even hundreds of code changes in a branch being merged to trunk? What if your QA work is being done by people who are not developers and who have no involvement in the merge process?
These are not just hypothetical issues. I work on a team which espouses the agile methodology, and many times we've missed bug fixes in merges because of the way Subversion treats moves (copy + delete instead of truly changing the parent directory of a given file), or because Subversion's merge facility got confused (especially when changes were made both to the branch and trunk versions of a file).
Recently, I was put in charge of merging a branch to the trunk for my team's project, and discovered that some methods were duplicated because one of our programmers had deleted the original version of a given method, then pasted in a completely different implementation into a different location in the same source file. It was easy enough to catch this with Java classes (since they won't compile correctly if you have two instances of the same method signature in the same class), but JavaScript was a slightly different story...
they're actually crying because Intel is advertising a more expensive laptop to the same customers
Actually, it's a bit deeper than that. Intel is spreading FUD about the OLPC project in general, and about the XO (the OLPC laptop) in particular. This is not unlike Microsoft's vaporware product announcements designed to forestall customers adopting or migrating to software made by Microsoft's competitors. The difference here is that Intel's product offering is not exactly vaporware. What it is, though, is a more expensive piece of hardware that's being subsidized by Intel to force market adoption, at the expense of OLPC. The accusation here is that Intel is pricing their offering below-cost to drive OLPC out of the market. Here in the U.S., the practice is called "dumping," and is ostensibly illegal.
If OLPC becomes stillborn due to Intel's efforts (an outcome Intel would probably welcome), do you think Intel's commitment to their own laptops-for-kids initiative will persist, or will it evaporate?
Normally, I wouldn't comment, but it seemed to me you were heaping a bit of undue scorn on the AC poster. The 80-core prototype processor was covered previously on Slashdot.
ArsTechnica has good coverage, and you can find more at C|Net. Incidentally, the AC was right -- simply googling for "Intel 80 core processor" yields plenty of results. (Googling for "Intel 80 core processor Slashdot" will find the Slashdot article to which I provided the link.) Instead of ripping on the guy for being passive-aggressive, maybe you should stop and research before posting a comment insinuating that the AC poster is just spreading FUD. This story was covered well enough recently that a hyperlink citation shouldn't have been strictly necessary.
Um, your temperature conversions are wrong. 4F = approx. -15.6C, and 20C = 68F. The conversion equations can be found many places, such as here.
I also initially disbelieved your explanation, since my high school physics textbook unambiguously attributed the ice skating phenomenon to regelation, but further digging did turn up this little gem (and a related tidbit showing a classic regelation experiment):
Beware: if you search for ice regelation on google, some web sites propagate the error that the mechanism of ice skaing is regelation. As you can calculate in the question sheet, regelation does not give sufficient depression of the melting point over long enough for it to be important for ice skating.
And from the related page:
It seems clear from the literature (but disappointing) that regelation is not the cause of the ice being slippery when you ice skate. A paper published in Physics Today in December 2005 and listed in the references for this demonstration, discusses the concept, initially proposed by Faraday, that a microscopic layer of water, found on ice even at very low temperatures, is responsible for ice being slippery. On the other hand, regelation apparently is a primary contributing cause for the motion of glaciers, as discussed in one of the references.
Another curious side note from that last link:
There is a lot of discussion about whether this really demonstrates regelation, but rather simply conduction of heat by the wire to the ice cube so that it will melt, followed by freezing over of the cut due to conduction of heat away from the cut to the surrounding ice.
Interestingly enough, a fellow student in high school eliminated this potential problem when she recreated the regelation experiment -- she put the entire experimental apparatus inside a freezer unit with excellent temperature control, so she was able to vary temperature as well as the masses attached to the metal wire, and she was able to insure that the masses and wire were at the same approximate temperature as the block of ice.
More info can be found here, which gives some interesting extra info (such as: the optimum temperature for speed skating with minimal friction is -7C).
Slashdot Mirror
Unless you're dealing with exceptions that subclass RuntimeException -- those don't need to be declared in a method signature, because they're unchecked exceptions. If you are trapping a condition that's truly exceptional and might not be recoverable, an unchecked exception makes sense (and saves you from a lot of try/catch blocks in your code).
Actually, I've worked with a number of horrible and mediocre programmers (some of them ex-Motorola people), and I can tell you definitively that Java does not save them from themselves. It doesn't even do a good job of protecting the good programmers from dealing with the messes made by bad programmers. Judging from the rest of what you wrote, it sounds like an academic laundry list of complaints about Java, and not a set of complaints written by someone who's ever had to write a nontrivial piece of code in Java.
Totally unsubstantiated posturing. Also totally ignores one of the real problems with Perl (and even Ruby, to a lesser extent) -- code maintainability. Production Perl code I've seen is almost uniformly hairy and impossible to maintain -- sometimes even by the person who wrote it originally. Java enforces standards and conventions which improve productivity and maintainability. When you consider that 80% of the cost of any software project is in the maintenance, that's a major factor. That's the real reason why people who manage IT like Java and C#, not because they're trying to oppress you.
Viewed that way, Perl and Ruby become great languages to do prototyping, or to do quick, one-off programs that accomplish something that you wouldn't want to do in some lesser shell scripting language. The flexibility you cite becomes an advantage in these cases. But I would not want to revisit Perl code for a utility that's going to be in use for any length of time; hence, I would say Ruby is the superior tool in this instance. I still wouldn't want to use either for any kind of substantial enterprise application development.
They're called "generics" in Java. They also don't work quite the same way as C++ templates. In fact, Java generics basically take care of the casting behind the scenes for you; they just help insure that everything is typesafe at compile time, so you don't have to deal with ClassCastExceptions at runtime.
Well, I know laziness is considered one of the car
You can't make a patent "public domain," but you can dedicate a patent, which effectively means that anyone can use the patent without paying licensing fees. It also guarantees that nobody else can (legally) claim a patent covering the same invention.
Standard IANAL disclaimer applies.
Actually, IE 5.x on Mac OS X had full PNG alpha channel support, with compositing and everything. It was one of the browsers with which you could showcase pages like this one.
I already addressed this issue in a sibling comment to yours, but I figured I'd address this specific point here (as I'm one of the authors of the PNG spec).
PNG was only ever intended to be a format to store image data, not animation data. The use of GIF animations wasn't very widespread when the GIF LZW patent crisis prompted a group of developers to work on the PNG specification. MNG is the sister format, is specifically intended to cover animation applications, and builds upon the PNG specification. (Without glancing at the specs, I recall that a PNG is more-or-less a valid MNG file, but not the other way around -- MNG is therefore a superset of PNG. Although I worked on the PNG spec, I have no real connection to the MNG folks.)
APNG was an effort that originated outside the PNG/MNG group, and it failed to be ratified as an extension to PNG -- mainly because it goes contrary to the mission of PNG, which is to be a standard for storing single images. The rejection of the APNG proposal happened earlier this year, according to the Wikipedia article. Apparently undaunted, the Mozilla folks stuck APNG support into Firefox, but who knows if it'll stay there. The format extensions for APNG are officially unsupported and non-standard, making Firefox the lone holdout on this. Why they couldn't just support MNG is anyone's guess.
Basically, by the time animated GIF became a serious issue, the PNG spec was very close to frozen, and the core spec authors and library developers successfully argued that PNG should be kept solely for image storage. (During PNG development, a THMB chunk was proposed to store a thumbnail version of the full image. This was killed for similar reasons to the APNG extensions.) I tend to agree that stuffing animation features into a file format intended for still images makes the decoder more complicated, and doesn't offer a very optimal solution for animation. The whole notion of animated GIFs never sat well with me either, even though they proved to be popular with HTML jockeys.
Further reading seems to indicate that Mozilla's developers had MNG support, but yanked it in favor of APNG support. I can only guess the motivations, but sounds to me as though they wanted to blaze their own path for political/personal reasons, not necessarily sound technical reasons.
PNG was always intended to replace GIF and be a "better GIF than GIF." PNG is also a more-than-adequate replacement for most common TIFF variants, because you can do almost everything that TIFF can do, but with less complexity (fewer choices for implementation, simpler format, and no optional format features you can't live without that some readers may choose to ignore) and less ambiguity in the spec. The less ambiguity bit is important, since the TIFF spec's ambiguity is one of the main reasons that TIFF files written by one application may not be readable by another application -- even if both apps support the same TIFF extensions.
PNG has compression -- it uses deflate (LZ77 + Huffman coding) instead of GIF's formerly-patent-encumbered LZW algorithm. The key here is lossless compression, so unlike bog-standard JPEG, PNG images are great for archiving exact image data. Radiologists like the fact that PNG can store grayscale images with 16-bit-per-pixel accuracy, in complete image fidelity.
Yes, PNG has better alpha channel support than GIF (although it has a special palette-based transparency feature similar to GIF89's transparency, mainly to ease the transition from GIF to PNG). It also has a better interlacing scheme, for progressive rendering of images when your data pipe is constrained. Set-top-box developers like this feature.
Where PNG fails with high def photos and the like is the lack of floating point representation of pixel data, which limits the kind of High Dynamic Range stuff you can do with it. PNG has chunk types which can contain many of the kinds of meta-data that you would care about for digital photography and scanned artwork, but much of the reader code out there does nothing with this meta-data.
Actually, PNG doesn't support animation at all. The animated sister format is MNG. Animated GIFs are kind of a poor animation format anyway, but they're great for small-size effects on web pages. MNG support in browsers is non-existent, so this has paradoxically limited PNG's uptake (and made GIF more difficult to kill).
It didn't help Be that Metrowerks pretty much abandoned development on the developer tools for BeOS, and had no intention of even telling Be, Inc., that the effort was being quietly halted. I know because I was the last hire for the "Be Hive," when Metrowerks was still headquartered in Austin, TX. I was going to relocate from Phoenix to Austin for this job, and then one day my boss called me at my house in Phoenix (where I was working while trying to market my house so I could relocate) to let me know what was going on.
At that point, I was offered a chance to switch to one of Metrowerks' other divisions, but I declined, since I really had taken the job because of the BeOS development work. (Actually, I gave my boss a really inflated estimate for how long it would take me to sell my house and move, and that had the same general effect. Kind of like saying, "Gee, my motivation to move has just been destroyed.")
What pissed me off is that the company had no plan or (apparent) intention of warning Be or handing off development in a coherent, sensible way. Fortunately, Be found out through the grapevine, but by that point, they'd lost a major ally.
Later on, I ran into Dominic Giampolo at Comdex; I had seen him a couple times at the Metrowerks office in Austin, so we exchanged warm greetings after I reminded him of who I was. Dominic told me I should say hi to Jean Louis, but warned me to downplay the Metrowerks connection because feelings were still a bit raw over that whole incident.
Had Be been given a fair shake, there's no telling what they could have done. I think BeOS would have been a great PDA/smartphone OS, and before I left Metrowerks, I saw evidence in the Be header files that they had porting efforts underway for CPU architectures like the Hitachi SH-3/4 (which were popular chips for PDAs at the time).
THX is mostly marketing these days, true, but you'd be amazed at how much it costs to get THX certification for a piece of home theater hardware. (I have a high current power amp which is THX certified, and although it's an impressive piece of hardware, there's little about the design that specifically was required by THX -- basically, the amp vastly exceeded the minimum power and distortion requirements, and the manufacturer put a couple of trimpots on the inputs so you could do careful level adjustment.)
I suspect much of the price differential between the Series 3 and the "Lite" is due to the omission of THX certification. The removal of the OLED display and the switch to some more integrated chips (and a cheaper mainboard) all help keep manufacturing cost down, but those changes by themselves aren't enough to explain the huge price drop.
I think the confusion stems from the comparison table in Ars' article, which gives prices for both the Series 3 and the Series 3 Lite, and notes that although the Series 3 has an MSRP of about $800, it can be had for about $300 cheaper due to rebates, sales, and other promotions.
Look, if you're going to berate someone for being an idiot, at least try to make yourself look a little more intelligent by spelling "recurrence" correctly, and using some basic capitalization and punctuation. Bonus points if you can tell the difference between stupidity and ignorance, since the issue you're taking task with could just as easily be ascribed to ignorance as to stupidity. (Since you don't know which is the case, it's kind of rude to assume the worst case about someone you've probably never met and know nothing about.)
Oh, also, Nietzsche (note the spelling) didn't invent the concept of Eternal Recurrence. It's a pretty old concept.
No, the mitochondria use oxygen and glucose (well, the byproducts of glycolysis) to manufacture ATP using the Krebs cycle. Please see the Wikipedia article on Mitochondria for more info.
But yeah, thanks for implying that fans who re-watch movies regularly are somehow brain damaged. I suppose you think people who re-read their favorite books are also similarly mentally challenged... even though many published authors will read and re-read the works of other writers to get ideas and to try and infuse some of the other writer's style into their own. Yeah, they must all be brain damaged too.
Whoops, scratch what I said about QAM. After more careful reading, it looks as though EIT is available for cable systems in the U.S., although the article cited doesn't address the issue of encrypted QAM (which most open hardware and software can't decrypt, making the QAM capabilities of most HD tuner cards limited at best). So even though EIT might be technically available for digital cable users in the U.S., it might not be practically accessible to MythTV. And there are no guarantees for how far in the future scheduling data will be provided.
I've seen some of the newer LCD HDTVs sold here in the U.S. which have the ability to display program guide data, no doubt culled from available EIT data, but this is really intended to allow viewers to see what's on right now or in the immediate future without resorting to channel flipping. I bought a Sharp Aquos one generation before this feature became standard, so I missed out, but I really don't feel like I'm missing too much because of the described limitations.
But for the aforementioned reasons, you wouldn't want to use water as your basis for defining mass accurately. Counting discrete things like atoms seems to be a smarter way to go, overall.
Not 100% correct. The designs of the characters are not copyrightable in the US, sure, and this is by intent. You can clone any popular typeface by reverse engineering and sell it or give it away, no problem. However, there are two kinds of protection that computer fonts can and do enjoy:
Currently, the United States is the only country (according to certain partisans, anyway) which does not recognize the copyrightability of non-computer fonts. So your statements are even wrong on the international level. Many countries recognize font designs as artistic works.
Regardless, companies like Adobe and Microsoft can and do claim copyright on PostScript and TrueType fonts. The PostScript case is fairly clear, since PostScript is a complete programming language, and thus such fonts can be copyrighted as software. See also this BoingBoing post which actually cites precedent for Adobe and Emigre Fonts successfully suing another software vendor over computer fonts. In such cases, the rulings talk about "font software programs."
Well, that statement makes a gross assumption. Every software developer (programmer/engineer) thinks that their particular domain is representative of what computer programmers do in general. However, if you in fact write software that automates common business tasks, the software is directly analogous to the process it seeks to model and/or replace. Most business tasks are sequential, so procedural single-threaded programming is a perfectly fine model to use.
Yes, for the things that most casual users and computer scientists think are "interesting," there is some inherent level of parallelism that can get pretty high. For a few choice types of tasks (ray tracing, rendering certain fractals), the problem itself is embarrassingly parallel because there is no direct coupling between the solutions of sub-problems. However, at some level you can't decompose your problem any further, and you can extract no more parallelism.
The vast majority of computer software these days is written for businesses. Most of it is not the stuff you see on the shelf at the local computer store, but is written custom to solve a specific business need. Most business processes are inherently serial operations: you perform one step, then you perform another step that depends on the previous step. Occasionally, you get lucky and you discover multiple steps that can be done simultaneously. However, making such processes explicitly parallel might not be the most advantageous move; after all, most modern CPU architectures are adept at out-of-order execution, and can analyze instruction streams to figure out dependencies dynamically. Heck, most modern CPU architectures support multiple in-flight instructions, and allow multiple instructions to complete simultaneously, which extracts parallelism at a very low level.
You can still explicitly use this technique in modern programming languages; Java, for example, has Thread.join() which is used for precisely such situations. However, just because you can do something doesn't mean that you should; there is overhead associated with spawning threads of execution and synchronizing threads when some result is needed. If the computation being performed by a function call is long-lived, then it makes sense to spawn a thread to perform that computation -- assuming that there are sufficient computational resources to truly run that thread concurrently (e.g., another CPU core able to perform that computation). Otherwise, you're burning more computational resources and probably making your code actually slower in the process (due to management overhead). And if you're multitasking on a single CPU core, spawning another thread will almost certainly result in a slower-running program (because you still have all the overhead of managing another thread, but none of the benefit of true hardware-level concurrency).
The first sentence is really an unsupported conjecture. The second sentence is an attempt to provide anecdotal evidence drawn from your own experiences to support the conjecture in the first. My own life experience is vastly different from yours, but then again, that too is anecdotal evidence; neither your nor my personal experiences are really "proof" o
The obvious solution to your problem is to avoid using special-purpose music CD recording devices, and instead use your computer's CD-ROM drive to do the ripping. Then you can burn as many copies as you like, since computer CD drives totally ignore the "no copy" bit on CDs. SCMS never even comes into play with such systems.
Yeah, some lawyers may argue that such use violates the spirit of the AHRA. Then again, the ability to "Rip-Mix-Burn" has been legally challenged, and found to be a non-infringing fair use in the United States. Some lawyers might claim that ignoring the "no copy" bit on CDs is a DMCA violation, but since computer CD-ROM drives were never obligated to pay attention to this bit (and since computer manufacturers are not obligated to adhere to the AHRA), it's hard to argue that SCMS is any kind of effective technological measure to prevent copying. It's only effective if you stay within the prescribed ecosystem of SCMS -- devices that are primarily designed for recording and playing back digital audio.Absolutely nothing in practice. This is the same way that record labels get away with releasing "copy protected CDs" which don't technically adhere to the Red Book standard. Of course, the licensing authority does have the power to say "You can't sell this disc as XYZ unless it adheres strictly to this specification," and that actually has some force. But most consumers don't even pay attention to the stickers that say "This disc contains copy protection technology and may not play on all CD players," or something similar.
Managed copy was a feature pushed by the device manufacturers and computer companies backing these next generation optical discs. (See this article for more info.) The movie studios never wanted managed copy, but IIRC, HP and some other players pushed the managed copy feature as part of the spec. HD-DVD had mandatory managed copy as a selling point vs. Blu-Ray initially, and the Blu-Ray camp responded by adding managed copy as an option to the Blu-Ray spec, but it's not mandatory, so studios get to pick which discs support it. (HP also tried to push the Blu-Ray group to include iHD, but they refused, since they're pushing BD-J.)
As for who's actually implementing managed copy, that's a problem. Early adopters will discover that the first generation of Blu-Ray and HD-DVD players won't support managed copy at all, and won't be firmware upgradable to do it either. That's what happens when you let hardware manufacturers forge ahead without finalized specs.
Far be it from me to defend anything about Islam, but... my understanding is that "Islam" means "submission," as in "submission to God's will." Of course, this is unpalatable to me for several reasons (not the least of which is the implication that the relationship between God and Man is one of Master and slave), but "repression" and "submission" are two different things.
Repression is what someone in a position of authority does to you (whether that's secular authority or religious authority; even self-imposed repression is typically carried out in service to someone else's ideology), and submission is something that you do yourself (whether that submission is voluntary or externally forced). Of course, one can lead to the other.
What if the merges are done by someone who isn't familiar with all the code changes and the expected associated application behaviors? What if there are dozens or even hundreds of code changes in a branch being merged to trunk? What if your QA work is being done by people who are not developers and who have no involvement in the merge process?
These are not just hypothetical issues. I work on a team which espouses the agile methodology, and many times we've missed bug fixes in merges because of the way Subversion treats moves (copy + delete instead of truly changing the parent directory of a given file), or because Subversion's merge facility got confused (especially when changes were made both to the branch and trunk versions of a file).
Recently, I was put in charge of merging a branch to the trunk for my team's project, and discovered that some methods were duplicated because one of our programmers had deleted the original version of a given method, then pasted in a completely different implementation into a different location in the same source file. It was easy enough to catch this with Java classes (since they won't compile correctly if you have two instances of the same method signature in the same class), but JavaScript was a slightly different story...
Actually, it's a bit deeper than that. Intel is spreading FUD about the OLPC project in general, and about the XO (the OLPC laptop) in particular. This is not unlike Microsoft's vaporware product announcements designed to forestall customers adopting or migrating to software made by Microsoft's competitors. The difference here is that Intel's product offering is not exactly vaporware. What it is, though, is a more expensive piece of hardware that's being subsidized by Intel to force market adoption, at the expense of OLPC. The accusation here is that Intel is pricing their offering below-cost to drive OLPC out of the market. Here in the U.S., the practice is called "dumping," and is ostensibly illegal.
If OLPC becomes stillborn due to Intel's efforts (an outcome Intel would probably welcome), do you think Intel's commitment to their own laptops-for-kids initiative will persist, or will it evaporate?
Normally, I wouldn't comment, but it seemed to me you were heaping a bit of undue scorn on the AC poster. The 80-core prototype processor was covered previously on Slashdot.
ArsTechnica has good coverage, and you can find more at C|Net. Incidentally, the AC was right -- simply googling for "Intel 80 core processor" yields plenty of results. (Googling for "Intel 80 core processor Slashdot" will find the Slashdot article to which I provided the link.) Instead of ripping on the guy for being passive-aggressive, maybe you should stop and research before posting a comment insinuating that the AC poster is just spreading FUD. This story was covered well enough recently that a hyperlink citation shouldn't have been strictly necessary.
I also initially disbelieved your explanation, since my high school physics textbook unambiguously attributed the ice skating phenomenon to regelation, but further digging did turn up this little gem (and a related tidbit showing a classic regelation experiment):And from the related page:
Another curious side note from that last link:Interestingly enough, a fellow student in high school eliminated this potential problem when she recreated the regelation experiment -- she put the entire experimental apparatus inside a freezer unit with excellent temperature control, so she was able to vary temperature as well as the masses attached to the metal wire, and she was able to insure that the masses and wire were at the same approximate temperature as the block of ice.
More info can be found here, which gives some interesting extra info (such as: the optimum temperature for speed skating with minimal friction is -7C).