Those classes and libraries represent a lot of work a developer doesn't have to figure out themselves
What? Those classes represent a lot of work the developer absolutely has to figure out themselves. Nobody just looks at J2EE and goes, "hey, that makes sense." J2EE costs time and money, it doesn't save time and money.
Interesting observations. Apple did try to solve this problem with AppleScript, but there were too many unproven ideas in there together. The part you want would have been achieved if it were easy enough to develop with that you could implement your GUI by sending AS messages to your objects. If you run Script Editor on your Mac, you'll see a Record button. That button worked, ostensibly, by snooping the AS events as they were fired by interacting with your GUI.
I think this failed to take off, or got forgotten, because AppleScript-the-language is a terrible piece of crap as well as because the behind-the-scenes mechanics of making it work are very 1980's indeed: four character message codes at the heart and allowing each application to interpret the grammar as it desires without a common framework adds up to a real stew of misery.
Having used Smalltalk in the last couple years, I find it very hard to see a resemblance between the 1980's layer we're living with and the 1980's layer we ought to have if Smalltalk had won out. In Smalltalk-land, there are no command line tools not because Smalltalk can't model pipes and files (the stream API is very important) but because writing a GUI is not much work compared to writing a CLI. When you can open a Workspace to create and send messages to your objects directly, or inspect live instances and modify their data or send them messages directly, the need for a terminal emulator is radically diminished. With Morphic, if you don't like the way a GUI button works—or if you want a copy of it—you can inspect it and edit it live, right in the context, find out what it's doing and write code to run it elsewhere. It's equally powerful to scripting, just alien.
And of course, the modern systems we're living with derive only their most basic aspects from Smalltalk. That moron James Gosling considered the big miracle from Lisp to be garbage collection, so of course the big miracle from Smalltalk was probably something equally trivial that missed the point utterly. Cocoa at least got message selectors. The resemblance is still very faint. Every year someone announces an amazing new Java framework that is capable of doing something Smalltalk was doing in the mid-90's.
All the same, there is an impedance mismatch here. I quite like how Plan 9 dealt with the mismatch, which is by making the rest of the system work through everything-is-a-file, including the UI, the authentication mechanism, the networking, everything. This must be terrifically handy for scripting, but judging by how thoroughly it's taking over the world, it must have left something to be desired in the compatibility department, and perhaps in the ease-of-programming department as well. (If you look at everything Rob Pike has been involved with, they're all variations on Unix + C with an obsession with parallelism, pretty far from RAD)
I held out some hope for KDE, mostly because I bought the propaganda about being able to optimize the system and make large changes to it without redoing a bunch of work. In practice, I think KDE did better than GNOME, which with each release seemed to remove more functionality without becoming something newer and better, but KDE is also firmly and obviously trying to recreate and improve on other user interfaces, mainly Windows. Not a lot of radical innovation. I'm back to using FVWM at work, because I wanted something quick, simple, and, haha, scriptable. It's shocking how fast it is on today's hardware.
I see more of this bullshit coming, not less. Each year the web app situation gets more complex. It won't be long before it gets so complex someone will make a simplifying system on top of it, and we'll jump in and start about making it more complex again. I'm not jazzed about the idea. I hope some people come along and try to rework everything from the ground up, but each year, that becomes a bigger job. I hope, but I have doubts. Plan 9 and BeOS were, I thought, the best shots at making something radically different, but I'm just as disappoint
I'm pretty sure if you're born in this country, you're a citizen of this country. Granted, asking for someone to tell you they're born here isn't exactly the same caliber of data as knowing they're born here.
In my experience, Rubyists think profanity is cute ever since the famous DHH "Fuck You" slide.
Misconfigured Apaches dump PHP source code out all over the helpless user. Perhaps PHP developers swear less because they expect more eyes on the code due to this kind of accident.
It's quite reasonable to expect real databases to handle things like login and storing the passwords, especially if they're already storing users. This is, after all, what databases are for: data management. If you want multiple applications to use the same database (and you should, because databases are integration technology, not merely storage technology) then you want them all to be able to authenticate the same way, easily, and you want that functionality managed centrally with the data itself. PostgreSQL's supplied pgcrypto extension has a crypt function that works like bcrypt and uses whatever salt is stored in the password hash. The documentation shows how to use this to implement secure password storage and authentication.
Of course, if you're using MySQL, you already have an architecture problem.
I see your point, and it is an important one. Technologically, Bing is not actively performing searches on Google and importing that data into their index. However, I don't think this technological distinction is particularly relevant, and while we probably should dissect the technology involved a bit more, it's still obviously unethical at a minimum, probably a violation of Googles TOS, and possibly even a violation of more serious laws of broader scope.
Intuitively, it seems like the Bing toolbar must either single Google out for this treatment, or else send a vast amount of data back to Bing. The experiment described in the article is not sufficient to rule out the possibility that every time you enter text into a form and then click on a link it's not being sent to Bing. I don't think it would be particularly hard to create an experiment that would reveal whether or not the behavior is generic or specific to Google. If it's generic behavior, that would imply that Bing is tracking all kinds of typing + clicking behavior to feed its index, which sounds like an obvious privacy problem to me. Unless there's very sophisticated intelligence behind selecting whether or not to send the data, that could constitute a major breach of data, a potentially very big legal problem and not the kind of PR Microsoft would like to have in the corporate world. Site-wide bans of Bing or the Bing toolbar are not likely to do wonders for their brand.
If, on the other hand, the next experiment reveals that the code is wired up to Google as the article seems to assume, Bing is basing a substantive part of their algorithm on the fruits of Google's algorithm. Google's TOS, based on my non-lawyerly scanning, also is quite clear about use of the services being personal, non-transferrable and that any content they provide may not be transferred to another party with modifications. It would be easy for Google to sue Bing on the basis that by snooping on users clicks and reporting it back to Bing, they are utilizing a portion of the content created by Google for the user without permission. Google has really great lawyers. It would surprise me if a week passes before Microsoft is disabling the feature or Google has served them papers. It would also surprise me if the only basis for such a suit were Google's TOS and not obscure parts of our legal code as well.
I believe there are key differences between what's going on here and your analogy that invalidate the comparison. For one thing, it seems very unlikely that the Bing search bar is constraining its behavior to Google employees. Doing the kind of reporting that seems to be occurring also seems unlikely to be the kind of thing someone would consciously submit to. It may be a stretch to assume that this is only happening for search results on Google, but it's a similar stretch to assume that the Bing search bar is only reporting sufficiently anonymized statistical data and not much more personal information. The final distinction is that in search, in many ways the marketing data is the product. Stealing data about Google's search results is tantamount to stealing Google's search, whereas stealing marketing data about the McRat Burger doesn't necessarily give Burger King a recipe.
I'm willing to back off and reserve judgement over the coming weeks and months. If nothing happens, I'll certainly concede. On the other hand, if Google fights and wins a legal battle over this, or if Microsoft quietly changes their behavior, I hope you'll be willing to reconsider your position as well.
If you actually read the article, what you'd find is that they actually put fake search results into Google's database associated with random strings of characters. They searched for these strings on Bing and got no results, then searched for these strings on Google from IE and went back to Bing, and whaddayaknow, there were the results. This is like finding out that McDonalds got the Big Mac you're eating from the Burger King across the street in a different box.
All search engine business works by selling ads by usage. Usage is correlated to search result relevance. If Bing is a shell on top of Google, but selling their own ads rather than Google's, it's obviously a violation of Google's terms-of-service at least, if not breaking other laws about theft of intellectual property. Google doesn't maintain their algorithms and massive databases so that Bing can piggyback on them without paying for it.
Part of the problem with WebM is that it is so similar to H.264. I'd wager that if it is possible to "patch in" hardware support, it's also possible to sue Google for patent infringement. Which nobody is indemnified for.
I think if WebM and H.264 were technically indistinguishable, but WebM were an open format and patent-free, it would certainly be better than H.264. But they are not technically indistinguishable. Let me bring up some crucial points from Jason Garrett-Glaser's excellent analysis of WebM as a technology:
WebM's "specification" is laden with C code from Google's "reference implementation." It's not trying to be a standard in the sense of, here's the definition and some implementations, it's trying to be a standard in the sense of, everybody uses the same open-source implementation.
WebM is technically inferior to H.264. Jason points out that only in the lowest quality profile does it come close to matching H.264. However, to avoid certain obvious patents, they make the codec worse than it had to be. They also failed to optimize it for embedded devices.
WebM tries very hard to avoid H.264's patents, but is so similar in many places that it is hard to tell whether or not they have successfully avoided them.
If both were open and free, H.264 has technical merit over WebM, and that would be everyone's choice. However, I don't feel that just because there is a licensing fee involved with H.264, the technical merits just disappear. I also think WebM's legal situation is much less settled than people assume. If I were MPEG-LA, I would certainly be spending a lot of time and money determining all the ways I could argue that WebM infringes on my patents, and wait as long as reasonable to bring it to court in the hopes of getting the maximum in damages out of Google. People seem to have forgotten than Google is not indemnifying users of WebM. This means that if WebM is legally found to be infringing, all users of WebM could be liable, not just Google! This situation is far worse than with H.264, where the device manufacturer or software provider is the only one who can be on the hook. Google has essentially passed the legal buck.
Google may be posturing itself as saving us all from H.264 licensing fees, but they are simultaneously trying to lock us into an "open" specification that they have sole control over. I expect that before this battle is over, they will have spent more than H.264's licensing fees on litigation with MPEG-LA, defending WebM's high degree of similarity to H.264. Google is depending on our short attention spans white-washing them from all guilt for making this situation a bigger legal morass than it has to be. Let's not forget.
Additionally, it may be worth noting that Apple generally doesn't put release numbers on their products. My iPhone 4 just says iPhone on the back, and I'm pretty sure my 3GS only had iPhone on there too.
Yes and no. The Last Starfighter is a great kid's movie and unlike Tron, it has a workable plot. I have seen it recently and yes, there is a big dose of nostalgia, but it at least has the benefit of telling a story.
I realize this is mostly a diatribe for the sake of being controversial or perhaps preaching to the choir, but I believe you make a couple of good points in what you say, mixed in with few lies.
I am, first of all, not at all convinced that monkey patching has been a systemic problem in Rails. As far as I'm aware, there has been one situation in which the standard library acquired a method that had been patched in by ActiveSupport, leading to a rushed release to support a newer version of Ruby. If you look at the monkey patching situation in Rails today, mostly you see a bunch of handy methods in ActiveSupport and very little elsewhere. These are methods like pluralize, human_size, megabytes, etc, that enable you to write conventional code like "3.days.ago" and have it converted to a time object of some sort. Especially after the Merb debacle, emphasis in the core has been on solid interfaces and APIs, not magic hidden methods that can be magically overridden.
This does not fix what I consider to be a principle folly of Rails, which you point out: ActiveRecord. The emphasis in Rails is on programmer productivity, database be damned. Emphasis on MySQL also. I used to use a library called RedHillOnRails which furnished a lot of helpful stuff for PostgreSQL developers such as making the database generate foreign key constraints, using the database's constraints to avoid duplication in the ActiveModel code, and so forth. This library isn't really supported under Rails 3, which points to one of my primary objections to Rails and (to some degree) the wider Ruby community, which you allude to in talking about large amounts of software. There is a strong emphasis in this community on code heroics and so much code winds up on Github or someone's blog. It gets released, not particularly well-documented, and then the onus is on you to follow the person on Github or follow their blog, make sure you stay up-to-date when they tell you whatever's in the repository is stable, keep track of who is the current chaperone when the first guy loses interest (will_paginate is another example of this), and then you have to not be married to these libraries because when the next version of Rails comes out, you'll wind up throwing them away and using something else anyhow.
In the Java world, the APIs are rather stable, and the busy work is doing all of the "@Override public static final" and repeating yourself in the variable declarations (MyFoo foo = new MyFoo(...)). In Ruby/Rails, the busy work is staying up to date with APIs that constantly change and code that constantly changes hands.
The ORM situation is somewhat better in Rails 3, since you can now plug in Sequel, which does a much better job of staying out of your way, but lots of libraries expect you to be using ActiveRecord under the hood. Devise is a good example. It does everything and is simple to use, but if you're using Sequel, well, there's two people doing that and we got it to work through a bunch of uncool monkey patching. I have to ask myself, would I rather write this code myself or monkey patch it into working? Usually at the time, my answer is monkey patch it into working, but then it breaks a few months later and I don't have the stamina to keep making it work.
The ORM situation isn't any better in Java land though. Hibernate is a complete piece of shit. I've lost months of productivity to it and it doesn't perform for a damn because it flat-out does not make sense. It sounds like we're kindred spirits on this point though; SQL is my ORM.
Regarding testing, I never caught the testing bug myself. I blame Haskell, actually, which has made a lot of unit testing seem like busy work even when I'm using languages that can't detect the same range of errors at compile time that it can. However, I will say that out of all the Rails users I know, I am definitely the slacker when it comes to testing; one friend is very fond of test/unit and another has been an RSpec/BDD proponent for a long, long time. The problem with Ruby and Rails isn't a lac
Yeah, but until your ideas can be tested, they're not even hypotheses. Until today, it should have been "String Philosophy." And now it should be whatever the most politically correct term is for "theories" like alchemy.
We need least of all another reconfiguration of this broken idea. What we really need is to find a way to offer academic amnesty for string theorists, to get them to move to the humanities department where they belong.
It would be hard to be perceived as safe if their shit were always down. It isn't. Perception and reality aren't the same thing, but there's definitely a positive correlation.
How do you get $83K? 0.095 * 24 * 365 = $832.20/year. 0.13 * 24 * 365 = $1,138.80/year. The difference is $306.60/year. It's too much for hosting either way, but we're talking about a ~36% Microsoft tax, which isn't far from the ordinary.
m4 is no more a compiler than sed is. It's just a text macro expander, and it's not particularly complex. It takes about ten minutes to learn how it works, and if you're trying to configure sendmail or use autoconf, you owe it to yourself to spend the ten minutes.
The problem with sendmail is sendmail, not m4. It certainly needs too much configuration and its configuration is certainly too finicky, but that's a separate problem.
Organizations are required to take some responsibility for the actions of their supporters. WikiLeaks should strongly denounce the DDOSers. Whenever there's a major Islamist terror act in America, the neighboring mosques make a point of denouncing it. To do otherwise sends the message, at best, that they don't believe their actions were invalid. Again, it comes down to WikiLeaks behaving as though the rules of PR don't apply to them, which is a mistake.
While I can't speak to the quality of the press in other parts of the world, I find it hard to imagine that any group is well-equipped to drink down 600,000 cables and find the gems in a reasonable amount of time. I still think it speaks to WikiLeaks true motives that they haven't vetted the leak--neither they nor the leak were in this to expose an important wrong or pattern of bad behavior. I'm not referring in this case to the redaction process, which we agree, they tried their best to no avail. I am saying that they are after quantity rather than quality.
America isn't the only country in the world, but it is my home and it is the country I have the most vested interest in.
I don't disagree with you strongly, but I think there are a few points that make the situation a little murkier.
Protesters outside buildings carry signs that indicate why they're pissed off. When you DDOS a website, all you can do is take it offline. There's no way to see the protestors' messages online, so most of the citizenry who hear about this are going to hear about it from a news source. And as you know, the news sources in our country are much better at being entertainment than being unbiased or informative.
Also, at least in America, your right to protest does not grant you the right to interfere with my right to obtain services. So this protest is rather unlike picketing in at least two ways.
I also tend to agree with you about secrecy, but in this particular case, the vast majority of the content is diplomat A dissing diplomat B or country C. This is just politics. If you have more than a few friends, you probably have some things you tell one and some things you tell another and sometimes you tell one about the follies of another. That's just the way people are. Obviously it would be bad if one of your friends dissed another one and it got back to them, so it makes sense to me for diplomatic cables to be classified.
The other thing to note is that our government has many secrecy levels, and gaining access to the lower levels is not particularly hard. In this case, most of the cables are at low secrecy levels which are appropriate to their content. It's appropriate for our diplomat to Saudi Arabia to kiss the king's ass publicly and shit-talk him privately with superiors at home. That's what diplomacy is. Of course leaking this does damage, but it's far from being a threat to national security.
I argued earlier that WikiLeaks is using the wrong approach, and I think this is another fine example of it. Dropping tons of material on our country's feeble journalists will only make the story about the size of the leak rather than the content of it. They would do better to leak a little high-profile, actually bad stuff and then release the bulk. They're not leaking this with the intention of effecting positive change in our government by exposing unethical behavior. It's easy to see them as just leaking whatever secrets they can get their hands on for their own self-aggrandizement.
I agree with the idea of WikiLeaks, but the execution thus far leaves much to be desired.
Slashdot Mirror
While we're being pedantic, let's try spelling Gandhi correctly.
What? Those classes represent a lot of work the developer absolutely has to figure out themselves. Nobody just looks at J2EE and goes, "hey, that makes sense." J2EE costs time and money, it doesn't save time and money.
Interesting observations. Apple did try to solve this problem with AppleScript, but there were too many unproven ideas in there together. The part you want would have been achieved if it were easy enough to develop with that you could implement your GUI by sending AS messages to your objects. If you run Script Editor on your Mac, you'll see a Record button. That button worked, ostensibly, by snooping the AS events as they were fired by interacting with your GUI.
I think this failed to take off, or got forgotten, because AppleScript-the-language is a terrible piece of crap as well as because the behind-the-scenes mechanics of making it work are very 1980's indeed: four character message codes at the heart and allowing each application to interpret the grammar as it desires without a common framework adds up to a real stew of misery.
Having used Smalltalk in the last couple years, I find it very hard to see a resemblance between the 1980's layer we're living with and the 1980's layer we ought to have if Smalltalk had won out. In Smalltalk-land, there are no command line tools not because Smalltalk can't model pipes and files (the stream API is very important) but because writing a GUI is not much work compared to writing a CLI. When you can open a Workspace to create and send messages to your objects directly, or inspect live instances and modify their data or send them messages directly, the need for a terminal emulator is radically diminished. With Morphic, if you don't like the way a GUI button works—or if you want a copy of it—you can inspect it and edit it live, right in the context, find out what it's doing and write code to run it elsewhere. It's equally powerful to scripting, just alien.
And of course, the modern systems we're living with derive only their most basic aspects from Smalltalk. That moron James Gosling considered the big miracle from Lisp to be garbage collection, so of course the big miracle from Smalltalk was probably something equally trivial that missed the point utterly. Cocoa at least got message selectors. The resemblance is still very faint. Every year someone announces an amazing new Java framework that is capable of doing something Smalltalk was doing in the mid-90's.
All the same, there is an impedance mismatch here. I quite like how Plan 9 dealt with the mismatch, which is by making the rest of the system work through everything-is-a-file, including the UI, the authentication mechanism, the networking, everything. This must be terrifically handy for scripting, but judging by how thoroughly it's taking over the world, it must have left something to be desired in the compatibility department, and perhaps in the ease-of-programming department as well. (If you look at everything Rob Pike has been involved with, they're all variations on Unix + C with an obsession with parallelism, pretty far from RAD)
I held out some hope for KDE, mostly because I bought the propaganda about being able to optimize the system and make large changes to it without redoing a bunch of work. In practice, I think KDE did better than GNOME, which with each release seemed to remove more functionality without becoming something newer and better, but KDE is also firmly and obviously trying to recreate and improve on other user interfaces, mainly Windows. Not a lot of radical innovation. I'm back to using FVWM at work, because I wanted something quick, simple, and, haha, scriptable. It's shocking how fast it is on today's hardware.
I see more of this bullshit coming, not less. Each year the web app situation gets more complex. It won't be long before it gets so complex someone will make a simplifying system on top of it, and we'll jump in and start about making it more complex again. I'm not jazzed about the idea. I hope some people come along and try to rework everything from the ground up, but each year, that becomes a bigger job. I hope, but I have doubts. Plan 9 and BeOS were, I thought, the best shots at making something radically different, but I'm just as disappoint
I'm pretty sure if you're born in this country, you're a citizen of this country. Granted, asking for someone to tell you they're born here isn't exactly the same caliber of data as knowing they're born here.
In my experience, Rubyists think profanity is cute ever since the famous DHH "Fuck You" slide.
Misconfigured Apaches dump PHP source code out all over the helpless user. Perhaps PHP developers swear less because they expect more eyes on the code due to this kind of accident.
Try, yes, but they didn't do a very good job.
It's quite reasonable to expect real databases to handle things like login and storing the passwords, especially if they're already storing users. This is, after all, what databases are for: data management. If you want multiple applications to use the same database (and you should, because databases are integration technology, not merely storage technology) then you want them all to be able to authenticate the same way, easily, and you want that functionality managed centrally with the data itself. PostgreSQL's supplied pgcrypto extension has a crypt function that works like bcrypt and uses whatever salt is stored in the password hash. The documentation shows how to use this to implement secure password storage and authentication.
Of course, if you're using MySQL, you already have an architecture problem.
I see your point, and it is an important one. Technologically, Bing is not actively performing searches on Google and importing that data into their index. However, I don't think this technological distinction is particularly relevant, and while we probably should dissect the technology involved a bit more, it's still obviously unethical at a minimum, probably a violation of Googles TOS, and possibly even a violation of more serious laws of broader scope.
Intuitively, it seems like the Bing toolbar must either single Google out for this treatment, or else send a vast amount of data back to Bing. The experiment described in the article is not sufficient to rule out the possibility that every time you enter text into a form and then click on a link it's not being sent to Bing. I don't think it would be particularly hard to create an experiment that would reveal whether or not the behavior is generic or specific to Google. If it's generic behavior, that would imply that Bing is tracking all kinds of typing + clicking behavior to feed its index, which sounds like an obvious privacy problem to me. Unless there's very sophisticated intelligence behind selecting whether or not to send the data, that could constitute a major breach of data, a potentially very big legal problem and not the kind of PR Microsoft would like to have in the corporate world. Site-wide bans of Bing or the Bing toolbar are not likely to do wonders for their brand.
If, on the other hand, the next experiment reveals that the code is wired up to Google as the article seems to assume, Bing is basing a substantive part of their algorithm on the fruits of Google's algorithm. Google's TOS, based on my non-lawyerly scanning, also is quite clear about use of the services being personal, non-transferrable and that any content they provide may not be transferred to another party with modifications. It would be easy for Google to sue Bing on the basis that by snooping on users clicks and reporting it back to Bing, they are utilizing a portion of the content created by Google for the user without permission. Google has really great lawyers. It would surprise me if a week passes before Microsoft is disabling the feature or Google has served them papers. It would also surprise me if the only basis for such a suit were Google's TOS and not obscure parts of our legal code as well.
I believe there are key differences between what's going on here and your analogy that invalidate the comparison. For one thing, it seems very unlikely that the Bing search bar is constraining its behavior to Google employees. Doing the kind of reporting that seems to be occurring also seems unlikely to be the kind of thing someone would consciously submit to. It may be a stretch to assume that this is only happening for search results on Google, but it's a similar stretch to assume that the Bing search bar is only reporting sufficiently anonymized statistical data and not much more personal information. The final distinction is that in search, in many ways the marketing data is the product. Stealing data about Google's search results is tantamount to stealing Google's search, whereas stealing marketing data about the McRat Burger doesn't necessarily give Burger King a recipe.
I'm willing to back off and reserve judgement over the coming weeks and months. If nothing happens, I'll certainly concede. On the other hand, if Google fights and wins a legal battle over this, or if Microsoft quietly changes their behavior, I hope you'll be willing to reconsider your position as well.
If you actually read the article, what you'd find is that they actually put fake search results into Google's database associated with random strings of characters. They searched for these strings on Bing and got no results, then searched for these strings on Google from IE and went back to Bing, and whaddayaknow, there were the results. This is like finding out that McDonalds got the Big Mac you're eating from the Burger King across the street in a different box.
All search engine business works by selling ads by usage. Usage is correlated to search result relevance. If Bing is a shell on top of Google, but selling their own ads rather than Google's, it's obviously a violation of Google's terms-of-service at least, if not breaking other laws about theft of intellectual property. Google doesn't maintain their algorithms and massive databases so that Bing can piggyback on them without paying for it.
Part of the problem with WebM is that it is so similar to H.264. I'd wager that if it is possible to "patch in" hardware support, it's also possible to sue Google for patent infringement. Which nobody is indemnified for.
Damned if you do, damned if you don't.
Got nothing on Albuquerque cops. They took the chopper to Krispy Kreme to buy donuts.
Funny, I believed both of those were true leaks.
I think if WebM and H.264 were technically indistinguishable, but WebM were an open format and patent-free, it would certainly be better than H.264. But they are not technically indistinguishable. Let me bring up some crucial points from Jason Garrett-Glaser's excellent analysis of WebM as a technology:
If both were open and free, H.264 has technical merit over WebM, and that would be everyone's choice. However, I don't feel that just because there is a licensing fee involved with H.264, the technical merits just disappear. I also think WebM's legal situation is much less settled than people assume. If I were MPEG-LA, I would certainly be spending a lot of time and money determining all the ways I could argue that WebM infringes on my patents, and wait as long as reasonable to bring it to court in the hopes of getting the maximum in damages out of Google. People seem to have forgotten than Google is not indemnifying users of WebM. This means that if WebM is legally found to be infringing, all users of WebM could be liable, not just Google! This situation is far worse than with H.264, where the device manufacturer or software provider is the only one who can be on the hook. Google has essentially passed the legal buck.
Google may be posturing itself as saving us all from H.264 licensing fees, but they are simultaneously trying to lock us into an "open" specification that they have sole control over. I expect that before this battle is over, they will have spent more than H.264's licensing fees on litigation with MPEG-LA, defending WebM's high degree of similarity to H.264. Google is depending on our short attention spans white-washing them from all guilt for making this situation a bigger legal morass than it has to be. Let's not forget.
ffmpeg apparently does it. It's also the most widely used open source video library, and there aren't many other open source video encoders at all.
Additionally, it may be worth noting that Apple generally doesn't put release numbers on their products. My iPhone 4 just says iPhone on the back, and I'm pretty sure my 3GS only had iPhone on there too.
The grille is also pretty un-Apple these days.
I feel like I've been reading this article every six months for the last ten years.
Yes and no. The Last Starfighter is a great kid's movie and unlike Tron, it has a workable plot. I have seen it recently and yes, there is a big dose of nostalgia, but it at least has the benefit of telling a story.
I realize this is mostly a diatribe for the sake of being controversial or perhaps preaching to the choir, but I believe you make a couple of good points in what you say, mixed in with few lies.
I am, first of all, not at all convinced that monkey patching has been a systemic problem in Rails. As far as I'm aware, there has been one situation in which the standard library acquired a method that had been patched in by ActiveSupport, leading to a rushed release to support a newer version of Ruby. If you look at the monkey patching situation in Rails today, mostly you see a bunch of handy methods in ActiveSupport and very little elsewhere. These are methods like pluralize, human_size, megabytes, etc, that enable you to write conventional code like "3.days.ago" and have it converted to a time object of some sort. Especially after the Merb debacle, emphasis in the core has been on solid interfaces and APIs, not magic hidden methods that can be magically overridden.
This does not fix what I consider to be a principle folly of Rails, which you point out: ActiveRecord. The emphasis in Rails is on programmer productivity, database be damned. Emphasis on MySQL also. I used to use a library called RedHillOnRails which furnished a lot of helpful stuff for PostgreSQL developers such as making the database generate foreign key constraints, using the database's constraints to avoid duplication in the ActiveModel code, and so forth. This library isn't really supported under Rails 3, which points to one of my primary objections to Rails and (to some degree) the wider Ruby community, which you allude to in talking about large amounts of software. There is a strong emphasis in this community on code heroics and so much code winds up on Github or someone's blog. It gets released, not particularly well-documented, and then the onus is on you to follow the person on Github or follow their blog, make sure you stay up-to-date when they tell you whatever's in the repository is stable, keep track of who is the current chaperone when the first guy loses interest (will_paginate is another example of this), and then you have to not be married to these libraries because when the next version of Rails comes out, you'll wind up throwing them away and using something else anyhow.
In the Java world, the APIs are rather stable, and the busy work is doing all of the "@Override public static final" and repeating yourself in the variable declarations (MyFoo foo = new MyFoo(...)). In Ruby/Rails, the busy work is staying up to date with APIs that constantly change and code that constantly changes hands.
The ORM situation is somewhat better in Rails 3, since you can now plug in Sequel, which does a much better job of staying out of your way, but lots of libraries expect you to be using ActiveRecord under the hood. Devise is a good example. It does everything and is simple to use, but if you're using Sequel, well, there's two people doing that and we got it to work through a bunch of uncool monkey patching. I have to ask myself, would I rather write this code myself or monkey patch it into working? Usually at the time, my answer is monkey patch it into working, but then it breaks a few months later and I don't have the stamina to keep making it work.
The ORM situation isn't any better in Java land though. Hibernate is a complete piece of shit. I've lost months of productivity to it and it doesn't perform for a damn because it flat-out does not make sense. It sounds like we're kindred spirits on this point though; SQL is my ORM.
Regarding testing, I never caught the testing bug myself. I blame Haskell, actually, which has made a lot of unit testing seem like busy work even when I'm using languages that can't detect the same range of errors at compile time that it can. However, I will say that out of all the Rails users I know, I am definitely the slacker when it comes to testing; one friend is very fond of test/unit and another has been an RSpec/BDD proponent for a long, long time. The problem with Ruby and Rails isn't a lac
Yeah, but until your ideas can be tested, they're not even hypotheses. Until today, it should have been "String Philosophy." And now it should be whatever the most politically correct term is for "theories" like alchemy.
We need least of all another reconfiguration of this broken idea. What we really need is to find a way to offer academic amnesty for string theorists, to get them to move to the humanities department where they belong.
+1. This is the only worthy comment on this subject.
It would be hard to be perceived as safe if their shit were always down. It isn't. Perception and reality aren't the same thing, but there's definitely a positive correlation.
How do you get $83K? 0.095 * 24 * 365 = $832.20/year. 0.13 * 24 * 365 = $1,138.80/year. The difference is $306.60/year. It's too much for hosting either way, but we're talking about a ~36% Microsoft tax, which isn't far from the ordinary.
m4 is no more a compiler than sed is. It's just a text macro expander, and it's not particularly complex. It takes about ten minutes to learn how it works, and if you're trying to configure sendmail or use autoconf, you owe it to yourself to spend the ten minutes.
The problem with sendmail is sendmail, not m4. It certainly needs too much configuration and its configuration is certainly too finicky, but that's a separate problem.
Organizations are required to take some responsibility for the actions of their supporters. WikiLeaks should strongly denounce the DDOSers. Whenever there's a major Islamist terror act in America, the neighboring mosques make a point of denouncing it. To do otherwise sends the message, at best, that they don't believe their actions were invalid. Again, it comes down to WikiLeaks behaving as though the rules of PR don't apply to them, which is a mistake.
While I can't speak to the quality of the press in other parts of the world, I find it hard to imagine that any group is well-equipped to drink down 600,000 cables and find the gems in a reasonable amount of time. I still think it speaks to WikiLeaks true motives that they haven't vetted the leak--neither they nor the leak were in this to expose an important wrong or pattern of bad behavior. I'm not referring in this case to the redaction process, which we agree, they tried their best to no avail. I am saying that they are after quantity rather than quality.
America isn't the only country in the world, but it is my home and it is the country I have the most vested interest in.
Otherwise, I think we agree.
I don't disagree with you strongly, but I think there are a few points that make the situation a little murkier.
Protesters outside buildings carry signs that indicate why they're pissed off. When you DDOS a website, all you can do is take it offline. There's no way to see the protestors' messages online, so most of the citizenry who hear about this are going to hear about it from a news source. And as you know, the news sources in our country are much better at being entertainment than being unbiased or informative.
Also, at least in America, your right to protest does not grant you the right to interfere with my right to obtain services. So this protest is rather unlike picketing in at least two ways.
I also tend to agree with you about secrecy, but in this particular case, the vast majority of the content is diplomat A dissing diplomat B or country C. This is just politics. If you have more than a few friends, you probably have some things you tell one and some things you tell another and sometimes you tell one about the follies of another. That's just the way people are. Obviously it would be bad if one of your friends dissed another one and it got back to them, so it makes sense to me for diplomatic cables to be classified.
The other thing to note is that our government has many secrecy levels, and gaining access to the lower levels is not particularly hard. In this case, most of the cables are at low secrecy levels which are appropriate to their content. It's appropriate for our diplomat to Saudi Arabia to kiss the king's ass publicly and shit-talk him privately with superiors at home. That's what diplomacy is. Of course leaking this does damage, but it's far from being a threat to national security.
I argued earlier that WikiLeaks is using the wrong approach, and I think this is another fine example of it. Dropping tons of material on our country's feeble journalists will only make the story about the size of the leak rather than the content of it. They would do better to leak a little high-profile, actually bad stuff and then release the bulk. They're not leaking this with the intention of effecting positive change in our government by exposing unethical behavior. It's easy to see them as just leaking whatever secrets they can get their hands on for their own self-aggrandizement.
I agree with the idea of WikiLeaks, but the execution thus far leaves much to be desired.