Actually, this mentality comes from disenchantment with the legal system that is carefully cultivated by businesses to give themselves a legal leg up on consumers. If you convince people that the legal system is unable to decide consumer complaints justly according to their merits, then logically, there are only two choices: trust the corporations' word on everything or allow them to be torn apart by jealous parasites.
So, if you make people cynical about lawsuits by individuals, people see every consumer complaint as a threat to the production of all the food, services, and cool stuff that we currently enjoy. That is, a threat to capitalism and all we know as good.
Companies are happy to rely the legal system to regulate relations among themselves when they can't get along, of course. Then they gang up on consumers to exclude them from the system because they don't have to rely on lawsuits to hold consumers to their word -- that's what credit reporting services are for.
Frankly, I'd love to see our ridiculous liability system restored to some kind of sanity and credibility. Then corporations will have to face more public responsibility. These days, when a company gets walloped in court for blatant fraud and dishonesty, people don't take it very seriously because business interests make sure there's a steady stream of ridiculous personal injury lawsuits in the news. I have to admit they have a point, but they don't invest billions in cultivating our cynicism just as a public service.
I bet the average BlackBerry user consumes far less bandwidth than the average iPhone user. The iPhone is a media device; if you don't want media and web browsing, there's no reason to buy it. Many people with little interest in media and web browsing own Blackberries for purely business reasons. Plus, the iPhone's slick UI means people consume more bandwidth simply because it's more convenient. The lack of friction in the UI means iPhone users will start browsing the web at the drop of the hat, just because they're bored. Most people wouldn't access the web on a Blackberry without a reason -- at least that's true for a lot of older and cheaper Blackberry devices that account for many of RIM's subscribers.
I agree, but AT&T has always been known for mediocre cell service. If you aren't known for being good at something, there's no point in being better than adequate. Everywhere I go, the AT&T network seems barely adequate (though the data bandwidth can be excellent in off-peak hours.) I wouldn't know, but I assume it takes careful management to achieve such a consistent level of mediocrity. And they know that consistent mediocrity means that any aberration from normal conditions (such as an event that attracts an unusual number of people to one place) results in terrible service or no service at all. I've learned not to rely on my AT&T service. I'm looking forward to switching back to Verizon as soon as I can get a Verizon iPhone or something similar. Verizon has always hung their reputation on the quality of their network, so they have an incentive to keep it from crapping out all the time.
Short version: "We're sorry we changed something that worked and everyone was used to, but hey -- it's compliant with a standard." If this were Microsoft, we'd give them a healthy helping of humble pie, but because it's Linux and the magic word "POSIX" gets used, I'm sure we'll forgive them for it.
I think what we've learned is that there's a bug in the POSIX standard, and Ext4 exploits the bug to deliver high measured performance in a way that is actually bad for users. So it's a benchmark hack on top of a flawed spec -- all in all, a shit sandwich for users.
That's not to say that Ext4 is bad technology. It sounds like it will deliver on its performance promises on systems that run well-written, failure-resistent software. It just won't work with the software that desktop users currently use. It will take a while for this to get sorted out, and we have to moderate our expectations from "everyone switches to ext4 and gets an automatic speed boost" to "wait and see; desktop users might not benefit from it anytime soon."
This is the problem with new features - the users have problems using them until they fully understands and appreciates the advantages and disadvantages.
Advantages: Filesystem benchmarks improve. Real performance... I guess that improves, too. Does anybody know?
Disadvantages: You risk data loss with 95% of the apps you use on a daily basis. This will persist until the apps are rewritten to force data commits at appropriate times, but hopefully not frequently enough to eat up all the performance improvements and more.
Ext4 might be great for servers (where crucial data is stored in databases, which are presumably written by storage experts who read the Posix spec), but what is the rationale for using it on the desktop? Ext4 has been coming for years, and everyone assumed it was the natural successor to ext3 for *all* contexts where ext3 is used, including desktops. I hope distros don't start using or recommending ext4 by default until they figure out how to configure it for safe usage on the desktop. (That will happen long before the apps are rewritten.) Filesystem benchmarks be damned.
Ah, so instead of a bag that was gay in the sleek, urban, waxed-bikini-line way, you wanted a bag that was gay in the hairy, gun-polishing, unwittingly homoerotic, paramilitary-camaraderie, "let's practice jiujitsu so we can protect our families" kind of way.
Personally, neither way works for me, so I'm only gay in the "rarely has sex with women" kind of way.
(P.S. My current carry-on sucks, and I might end up buying a Tom Bihn Aeronaut as a result of this review, but why is this on Slashdot?)
A revolutionary new product type is conceived. "Everyone will want one! Everyone will have one!" Then a few products come out, and it turns out that only a few people want one. The conventional wisdom changes: "Never mind. Kinda lame. Just for gadget enthusiasts." Years later, Apple creates the first implementation that isn't a fiddly high-overhead pain in the ass to use. The revolution finally arrives. "Everybody wants one! Everybody has one!" Then other companies spend years trying to figure out how Apple's product is different from theirs. Thousands of people like me who kind of hate Apple hold out a few years and then give up and buy the Apple product.
I haven't decided whether I will wait out the iTable cycle, if that's what is coming. I can't stand OSX (I have a Mac Mini at home gathering dust because someone persuaded me I had to give OSX a chance,) but if the alternative is waiting until 2013 for a decent competitor, I'll buy, and I'll give Apple credit for another "first" regardless of the predecessors. Why? Because I'm familiar with some of the currently available tablets and have no desire to carry one around, and knowing fucking Apple, they will come out with a product I want to use, and I will have to swallow my resentment and buy one.
Software has to be designed to scale up and down through an acceptable range of hardware. If fast dev boxes spawn software that doesn't scale down, then slow dev boxes in the hands of the same developers just create the opposite problem: software that doesn't scale up to take advantage of multiple cores and gigs of RAM.
Wouldn't you rather piss off stingy customers than rich ones who are spending money on technology?
Jambi tried to solve the problem with Java (namely the UI libraries are terrible), but maybe it was too late?
It's far from an abandoned space. Jambi/Qt faces the opposite problem: trying to take market share away from two large, popular GUI application frameworks: Netbeans and Eclipse RCP. Eclipse RCP is already well-established as the platform of choice for Java programmers who want to build GUI applications using native widgets. GUI applications framework have a significant learning curve, so the uptake of Jambi/Qt among Java programmers will be gradual at best.
As the developer of a commercial Eclipse RCP application, I'll be disappointed if Jambi doesn't catch on. It seems like a simpler, light alternative to Eclipse and a good choice when you don't intend to build a heavy, complex application (which is what Eclipse RCP is good for, and not much else.)
No kidding. These obfuscated C winners impress the hell out of me, but in real life, I have yet to meet anybody who can code that way who doesn't think everybody should code that way all the time.
Most software distributors provide an easy, careless route through the installer -- just keep clicking OK. I think that's a fine thing to do, since most people just don't care. What do I need installed for Java to run well on my system? Don't tell me; just do it.
People who are more picky can find out what's going to be installed and opt out. They're a (supposedly) more sophisticated minority, so they can assume the relatively light burden of finding the checkboxes, understanding what they mean, and checking them or unchecking them as they desire.
Anyone who takes the careless route through an installer -- not taking the time to find out what the installer actually installs, and just clicking "OK" as fast as possible -- can't really complain if they end up installing something they didn't want, unless the installer is labeled in bad faith. That certainly wasn't the case here. Sun just wants their product to perform better in Firefox so people are more likely to have a positive perception of it.
Lack of documentation is so bad that many people won't read the documentation I write. They just aren't used to working that way.
It's a cultural thing, though. Some cultures are better than others. Java is WONDERFUL -- Java developers pretty much accept that missing or incomplete Javadoc in a public API is a serious bug. C and C++ are pretty pathetic. There are many extremely well-done and well-polished C and C++ libraries that have copious but holey documentation. You can tell the developers spent a lot of time working on the documentation but didn't really know how to do it -- probably because they've never bothered using documentation themselves. Typical documentation deficiences include:
The "success" behavior of every function is documented, but nothing is said about error cases. What if the arguments are invalid? Either the user adds a bunch of possibly redundant error checks to his code, or he passes bad arguments and hopes the library doesn't segfault his program.
The documentation says a function returns non-zero error codes in certain cases but does not document which error codes will be returned.
The documentation says that a function throws exceptions in certain cases but does not say which exceptions will be thrown. C++ developers in particular are notorious for misunderstanding the purpose of exceptions -- either they think no exceptions should be caught except at top-level, or they think all exceptions should be caught immediately. In either case, there's absolutely no point in documenting them. Of course that is entirely unrealistic. You don't want to pop up a dialog box saying, "This application has encountered a FileNotFoundException and may be unstable. It is recommended that you save all your data and restart." Neither do you want to catch a HolyShitInternalMeltdownError, log it, and continue with a pending database commit.
A function is documented to return a global error code whose documentation makes no sense in the context of that function, and no further information is provided.
Memory management is undocumented, or is documented in one obscure place that it takes two hours to find. So, if you look at the documentation for a function that returns a pointer, you have a hell of a time figuring out whose responsibility that object is.
The documentation tells you that a pointer returned from a function is to memory owned by the library, but it doesn't tell you how long the pointer is valid. You have to read the code or (more likely) make a common-sense guess and fix the code later if it segfaults.
When you pass a pointer to a library, the documentation fails to mention when you are allowed to deallocate that memory or whether the library will alter the data.
No documentation is provided at all, because then there are no bugs.
We discussed this issue back in 2006 [slashdot.org], though for a different continent. But if South Korea [phonescoop.com] and China [textually.org] can do it, why not the rest of the world?
Do we really want to mire ourselves in a soon-to-be-outdated technology standard? While South Korea has stood still on cell phone cable technology, the United States has forged ahead with a dizzying array of connector options. As a matter of principle, regulation (by government or voluntarily through industry consortia) shouldn't mandate where companies are allowed to innovate and where they are not.
In any case, the fact that American consumers (who have the freedom to do so) have been buying these specialized connectors and cables for years proves that consumers want them. That's common sense as well as basic economic theory -- which some Slashdotters seem to understand better than others.
I'm sure the handset makers are deeply saddened by this. Clearly, this unwelcome meddling by government will hurt consumers by ending competition in this vital technical matter. Why, instead of buying the latest high-tech replacement cable custom optimized for advanced synergy with their handset, people might replace a lost cable with an abandoned, misbranded, maybe even second-handed cable from an older handset. This could cost consumers literally incalculable amounts of synergy and innovation. Why won't the government just let capitalism work?
My bet is, long term, "bare metal binary" software will naturally disappear in favour of scripting languages, JIT compilation and/or virtual machine bytecode.
That's the long-term outlook, but in the short term, most developers are working in an older mindset, using a definition of "portable" that includes C. Of course, very few people are savvy enough to write completely portable C code, and even they make mistakes, so porting a C program to a new binary platform requires at least a code review and a bunch of testing.
In this C-centric world, binary compatibility remains extremely important even when you have access to source code.
VLIW has been more successful in other markets, such as embedded processors for telecom equipment. I got the impression from my computer architecture class (hopefully someone with more specific information can chime in here) that a VLIW processor beats the socks off x86 given a well-crafted stream of instructions, but compiler support was just too hard and never really materialized, so VLIW is used mostly used for special-purpose devices where the software hot spots can be hand-written (using C intrinsics or assembly) to make efficient use of the processor. Basically, given the lack of sufficiently intelligent compilers, VLIW platforms suck for general-purpose computing.
I'm not sure if I'm getting trolled or not, but....
And the determination of whether censorship is (or is not) occurring is immaterial to our response. And our response should be to copy and disseminate the allegedly censored information.
This is a recipe for abuse. Crying censorship is a regular tactic in art (where being comfortably tolerated by the establishment is the ultimate embarrassment,) commerce (get the new super cure that the pharmaceutical industry doesn't want you to know about!) and politics. Think of how often conservatives lament the liberal media that keeps them down, and how the liberals went on and on about Fox News hosts who shout over everything their guests say. Being censored is chic and always will be in a society that values freedom.
In this case the alleged victims are music bloggers, one of the most self-dramatizing and attention-whorish categories of people on earth -- yet these particular bloggers might have a legitimate complaint and might deserve support. You have to take each case on its merits, and you have to withhold help and publicity from attention whores so you can afford to give it to people who have been legitimately wronged.
Somehow, I don't think a few hundred regular posters and a few thousand regular readers on slashdot will do what over 170 governments to date have been unable to do. But I am open to any argument on how to go after the top fifty thousand major censors in the world utilizing the power of... keystrokes.
Your fatalism here is out of step with your eagerness for action elsewhere. Plus, why would you expect governments to go after censors? Governments in many cases are the censors, and when the censors are private entities, they are usually acting within their legal rights, so the government rarely helps. It does take keystrokes, or to put it another way, words. The chattering classes don't change things directly by their chatter, but through their chatter (or keystrokes -- maybe we should call them the "clattering classes") they decide how to wield their real power -- voting and consumption.
Nothing would make front page of Slashdot if we had to wait for all the facts to come in... Because nobody would read slashdot. Part of why slashdot is popular and exists is because it provides information quickly, not necessarily perfectly.
Point taken. I could go either way, but it seems at this point they need the attention of people who can help them investigate, so later the Slashdot headline wouldn't have to be phrased in the form of a question. It would help focus the conversation a bit;-)
Whether Google is censoring or not is irrelevant. What matters is whether anyone fights back.
I'm confused. Fighting back, supporting those who fight back, and bypassing censorship require knowing when censorship happens and who is responsible for it. By that reasoning, it's hard to see how it's irrelevant whether Google is censoring or not.
"Please stop." Please stop sharing information and doing collective investigation about censorship? Just fight back randomly against... everybody? Even those who don't censor? Work hard to find alternative means of distribution for... all speech? Even the stuff that hasn't been censored?
It seems more constructive to focus efforts on actual censors and instances of actual censorship. Hence, discussions like this are important and relevant. The facts have to be established before anyone knows what action to take. Whether this particular discussion should have made the front page of Slashdot before the facts were better established is another question (and IMHO the answer is "no.")
OpenOffice was big and slow long before it accumulated a nontrivial amount of Java code. The OpenOffice wiki lists exactly which functionality depends on the JRE. I don't see anything performance-critical in there. (Oh, and how did I know that? Because I've seen your argument debunked so many times on Slashdot it isn't even funny.)
As for Eclipse, I really don't understand. I have used Eclipse to write Eclipse RCP apps, and it's pretty miraculous the way it handles its own source code -- thousands of source files in many dozens of packages. If you compare IDEs by how quickly they pop up the "Print..." or "Save As..." dialogs, then Eclipse might rank near the bottom, but on large projects, I worry more about the performance hit of navigating, compiling, searching, and refactoring thousands of files. Eclipse does very well by those standards.
Eclipse support for C++ sucks ass compared to its Java support, though. If you tried developing C++ code in Eclipse then I'm sure it disappointed, but the problem there is not Java but the fact that C++ is not a big development priority for Eclipse.
It's quite handy for zero-based indexing. It's also convenient for splitting a big list into a bunch of little ones:
[a, b) = [a, a1) union [a1, a2) union [a2, a3) union [a3, b)
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 2, Insightful
That approach makes sense for small jobs, but for projects that take more than (say) two months, it makes more sense to choose a roughly suitable language, even if your proficiency is lower.
Also, for any code that isn't throwaway code, you have to assume that some unknown person will eventually inherit and maintain your code. Under that assumption, it's more important for the language to be appropriate for the task than for the language to be convenient for the initial programmer. You wouldn't want to inherit a bunch of string parsing code written in Fortran, would you? At least choose a roughly suitable language! Even the best imaginable regex library for C has to be relatively crappy (measured by the readability and correctness of code that uses it) just because of the limitations of the language.
Now, I personally detest Perl and am pretty good with C++, but if somebody proposed writing a string parsing program in C++, I would tell them to use whatever non-dead scripting language they know, even if it's Perl, and if they don't know one yet, for God's sake pick one and learn it -- even if it's Perl!
Ruby is meant to be more comfortable and expressive in the hands of a programmer than Python. That means more power and more elegance, but also less regularity, more features, and more emphasis on conciseness instead of readability and learnability. (Python is surprisingly readable for non-Python programmers, which I have found handy more than once.)
Personally, I use Python at work because I'm terrible at remembering linguistic features and syntax. At work almost every neuron in my brain is devoted to C++, so for everything else I need a nice, simple, even stupidly simple language that complements C++. Plus if someone inherits my Python code and says *gasp* "But I don't know Python!" I can honestly say, "Don't worry, you have nothing to worry about. You can learn it in a couple of days."
People tell me Ruby is more natural and expressive, and I believe them, but if Python ever lets me down I'm skipping straight to the Red Pill, aka Lisp, which I have enjoyed recreationally on occasion. (I keep some spare neurons for myself for fun. Don't tell my boss.)
In this case, the KDE team was clear that what the.0 meant was "API stable; will eat babies." It wasn't a huge secret, they plastered it all over the internet.
Well, let's see: http://kde.org/announcements/4.0/ Or check out the first Slashdot story. Unless you actually read through the comments, you'll never know. And isn't it the LEAST interested people who needed to know? They managed to warn everyone who was deeply interested in KDE4, when they really needed to reach and warn the casual users who ended up thinking, "Neat, it's finally here! I'll try it as soon as my distro makes it an option."
OSS is a big world, and nobody follows alls the news about projects they're only marginally interested in. Linus Torvalds was evidently a casual user of KDE who did not follow the news obsessively enough to have the correct, informed expectations of KDE 4.0 and 4.1.
And even if you're an OSS news junky, you got to read things like this on osnews.com:
KDE 4.0 is the first release of "KDE 4", but take note that the developers have clearly stated that KDE 4.0 is not KDE 4, but more of a base release with all the underlying systems ready to go, but with still a lot of work to be done on the user-visible side.
"KDE 4.0 is not KDE 4." Um, at that point they must have known that they were sending mixed, confusing messages. They could have used a different label for the release. Obviously they wanted broader exposure and credit for making a point-oh release. They got both, and they got the backlash.
"Early adopting users" is a relative term. Linux is getting more mainstream attention, and we should expect the language to change accordingly. KDE is a Linux desktop that intends to be usable for mainstream users. So anything they say about "early adopters" or "end users" can be interpreted in a bunch of different ways. I'm an "end user" by Slashdot standards but an "early adopter" by mainstream standards -- I figured I would be able to make 4.0 my default desktop at the expense of a few hours spent Googling and reading forum posts. It turned out to be a lot worse than that.
"Missing features" is pretty vague, too.
In contrast to that ambiguity, "this is the 4.0 release" is pretty clear, at least in the open-source world. Has the OSS world decided mainstream acceptance requires that.0 has to be a crapfest, and.2 should be the first usable version? I think OSS should be selective about adopting commercial software practices;-)
Slashdot Mirror
Actually, this mentality comes from disenchantment with the legal system that is carefully cultivated by businesses to give themselves a legal leg up on consumers. If you convince people that the legal system is unable to decide consumer complaints justly according to their merits, then logically, there are only two choices: trust the corporations' word on everything or allow them to be torn apart by jealous parasites.
So, if you make people cynical about lawsuits by individuals, people see every consumer complaint as a threat to the production of all the food, services, and cool stuff that we currently enjoy. That is, a threat to capitalism and all we know as good.
Companies are happy to rely the legal system to regulate relations among themselves when they can't get along, of course. Then they gang up on consumers to exclude them from the system because they don't have to rely on lawsuits to hold consumers to their word -- that's what credit reporting services are for.
Frankly, I'd love to see our ridiculous liability system restored to some kind of sanity and credibility. Then corporations will have to face more public responsibility. These days, when a company gets walloped in court for blatant fraud and dishonesty, people don't take it very seriously because business interests make sure there's a steady stream of ridiculous personal injury lawsuits in the news. I have to admit they have a point, but they don't invest billions in cultivating our cynicism just as a public service.
I bet the average BlackBerry user consumes far less bandwidth than the average iPhone user. The iPhone is a media device; if you don't want media and web browsing, there's no reason to buy it. Many people with little interest in media and web browsing own Blackberries for purely business reasons. Plus, the iPhone's slick UI means people consume more bandwidth simply because it's more convenient. The lack of friction in the UI means iPhone users will start browsing the web at the drop of the hat, just because they're bored. Most people wouldn't access the web on a Blackberry without a reason -- at least that's true for a lot of older and cheaper Blackberry devices that account for many of RIM's subscribers.
I agree, but AT&T has always been known for mediocre cell service. If you aren't known for being good at something, there's no point in being better than adequate. Everywhere I go, the AT&T network seems barely adequate (though the data bandwidth can be excellent in off-peak hours.) I wouldn't know, but I assume it takes careful management to achieve such a consistent level of mediocrity. And they know that consistent mediocrity means that any aberration from normal conditions (such as an event that attracts an unusual number of people to one place) results in terrible service or no service at all. I've learned not to rely on my AT&T service. I'm looking forward to switching back to Verizon as soon as I can get a Verizon iPhone or something similar. Verizon has always hung their reputation on the quality of their network, so they have an incentive to keep it from crapping out all the time.
Short version: "We're sorry we changed something that worked and everyone was used to, but hey -- it's compliant with a standard." If this were Microsoft, we'd give them a healthy helping of humble pie, but because it's Linux and the magic word "POSIX" gets used, I'm sure we'll forgive them for it.
I think what we've learned is that there's a bug in the POSIX standard, and Ext4 exploits the bug to deliver high measured performance in a way that is actually bad for users. So it's a benchmark hack on top of a flawed spec -- all in all, a shit sandwich for users.
That's not to say that Ext4 is bad technology. It sounds like it will deliver on its performance promises on systems that run well-written, failure-resistent software. It just won't work with the software that desktop users currently use. It will take a while for this to get sorted out, and we have to moderate our expectations from "everyone switches to ext4 and gets an automatic speed boost" to "wait and see; desktop users might not benefit from it anytime soon."
This is the problem with new features - the users have problems using them until they fully understands and appreciates the advantages and disadvantages.
Advantages: Filesystem benchmarks improve. Real performance... I guess that improves, too. Does anybody know?
Disadvantages: You risk data loss with 95% of the apps you use on a daily basis. This will persist until the apps are rewritten to force data commits at appropriate times, but hopefully not frequently enough to eat up all the performance improvements and more.
Ext4 might be great for servers (where crucial data is stored in databases, which are presumably written by storage experts who read the Posix spec), but what is the rationale for using it on the desktop? Ext4 has been coming for years, and everyone assumed it was the natural successor to ext3 for *all* contexts where ext3 is used, including desktops. I hope distros don't start using or recommending ext4 by default until they figure out how to configure it for safe usage on the desktop. (That will happen long before the apps are rewritten.) Filesystem benchmarks be damned.
Ah, so instead of a bag that was gay in the sleek, urban, waxed-bikini-line way, you wanted a bag that was gay in the hairy, gun-polishing, unwittingly homoerotic, paramilitary-camaraderie, "let's practice jiujitsu so we can protect our families" kind of way.
Personally, neither way works for me, so I'm only gay in the "rarely has sex with women" kind of way.
(P.S. My current carry-on sucks, and I might end up buying a Tom Bihn Aeronaut as a result of this review, but why is this on Slashdot?)
iPod, iPhone, and next, the iTablet?
A revolutionary new product type is conceived. "Everyone will want one! Everyone will have one!" Then a few products come out, and it turns out that only a few people want one. The conventional wisdom changes: "Never mind. Kinda lame. Just for gadget enthusiasts." Years later, Apple creates the first implementation that isn't a fiddly high-overhead pain in the ass to use. The revolution finally arrives. "Everybody wants one! Everybody has one!" Then other companies spend years trying to figure out how Apple's product is different from theirs. Thousands of people like me who kind of hate Apple hold out a few years and then give up and buy the Apple product.
I haven't decided whether I will wait out the iTable cycle, if that's what is coming. I can't stand OSX (I have a Mac Mini at home gathering dust because someone persuaded me I had to give OSX a chance,) but if the alternative is waiting until 2013 for a decent competitor, I'll buy, and I'll give Apple credit for another "first" regardless of the predecessors. Why? Because I'm familiar with some of the currently available tablets and have no desire to carry one around, and knowing fucking Apple, they will come out with a product I want to use, and I will have to swallow my resentment and buy one.
Software has to be designed to scale up and down through an acceptable range of hardware. If fast dev boxes spawn software that doesn't scale down, then slow dev boxes in the hands of the same developers just create the opposite problem: software that doesn't scale up to take advantage of multiple cores and gigs of RAM.
Wouldn't you rather piss off stingy customers than rich ones who are spending money on technology?
Jambi tried to solve the problem with Java (namely the UI libraries are terrible), but maybe it was too late?
It's far from an abandoned space. Jambi/Qt faces the opposite problem: trying to take market share away from two large, popular GUI application frameworks: Netbeans and Eclipse RCP. Eclipse RCP is already well-established as the platform of choice for Java programmers who want to build GUI applications using native widgets. GUI applications framework have a significant learning curve, so the uptake of Jambi/Qt among Java programmers will be gradual at best.
As the developer of a commercial Eclipse RCP application, I'll be disappointed if Jambi doesn't catch on. It seems like a simpler, light alternative to Eclipse and a good choice when you don't intend to build a heavy, complex application (which is what Eclipse RCP is good for, and not much else.)
No kidding. These obfuscated C winners impress the hell out of me, but in real life, I have yet to meet anybody who can code that way who doesn't think everybody should code that way all the time.
Most software distributors provide an easy, careless route through the installer -- just keep clicking OK. I think that's a fine thing to do, since most people just don't care. What do I need installed for Java to run well on my system? Don't tell me; just do it.
People who are more picky can find out what's going to be installed and opt out. They're a (supposedly) more sophisticated minority, so they can assume the relatively light burden of finding the checkboxes, understanding what they mean, and checking them or unchecking them as they desire.
Anyone who takes the careless route through an installer -- not taking the time to find out what the installer actually installs, and just clicking "OK" as fast as possible -- can't really complain if they end up installing something they didn't want, unless the installer is labeled in bad faith. That certainly wasn't the case here. Sun just wants their product to perform better in Firefox so people are more likely to have a positive perception of it.
Lack of documentation is so bad that many people won't read the documentation I write. They just aren't used to working that way.
It's a cultural thing, though. Some cultures are better than others. Java is WONDERFUL -- Java developers pretty much accept that missing or incomplete Javadoc in a public API is a serious bug. C and C++ are pretty pathetic. There are many extremely well-done and well-polished C and C++ libraries that have copious but holey documentation. You can tell the developers spent a lot of time working on the documentation but didn't really know how to do it -- probably because they've never bothered using documentation themselves. Typical documentation deficiences include:
We discussed this issue back in 2006 [slashdot.org], though for a different continent. But if South Korea [phonescoop.com] and China [textually.org] can do it, why not the rest of the world?
Do we really want to mire ourselves in a soon-to-be-outdated technology standard? While South Korea has stood still on cell phone cable technology, the United States has forged ahead with a dizzying array of connector options. As a matter of principle, regulation (by government or voluntarily through industry consortia) shouldn't mandate where companies are allowed to innovate and where they are not.
In any case, the fact that American consumers (who have the freedom to do so) have been buying these specialized connectors and cables for years proves that consumers want them. That's common sense as well as basic economic theory -- which some Slashdotters seem to understand better than others.
The threat of legislation was enough.
I'm sure the handset makers are deeply saddened by this. Clearly, this unwelcome meddling by government will hurt consumers by ending competition in this vital technical matter. Why, instead of buying the latest high-tech replacement cable custom optimized for advanced synergy with their handset, people might replace a lost cable with an abandoned, misbranded, maybe even second-handed cable from an older handset. This could cost consumers literally incalculable amounts of synergy and innovation. Why won't the government just let capitalism work?
My bet is, long term, "bare metal binary" software will naturally disappear in favour of scripting languages, JIT compilation and/or virtual machine bytecode.
That's the long-term outlook, but in the short term, most developers are working in an older mindset, using a definition of "portable" that includes C. Of course, very few people are savvy enough to write completely portable C code, and even they make mistakes, so porting a C program to a new binary platform requires at least a code review and a bunch of testing.
In this C-centric world, binary compatibility remains extremely important even when you have access to source code.
VLIW has been more successful in other markets, such as embedded processors for telecom equipment. I got the impression from my computer architecture class (hopefully someone with more specific information can chime in here) that a VLIW processor beats the socks off x86 given a well-crafted stream of instructions, but compiler support was just too hard and never really materialized, so VLIW is used mostly used for special-purpose devices where the software hot spots can be hand-written (using C intrinsics or assembly) to make efficient use of the processor. Basically, given the lack of sufficiently intelligent compilers, VLIW platforms suck for general-purpose computing.
I'm not sure if I'm getting trolled or not, but....
And the determination of whether censorship is (or is not) occurring is immaterial to our response. And our response should be to copy and disseminate the allegedly censored information.
This is a recipe for abuse. Crying censorship is a regular tactic in art (where being comfortably tolerated by the establishment is the ultimate embarrassment,) commerce (get the new super cure that the pharmaceutical industry doesn't want you to know about!) and politics. Think of how often conservatives lament the liberal media that keeps them down, and how the liberals went on and on about Fox News hosts who shout over everything their guests say. Being censored is chic and always will be in a society that values freedom.
In this case the alleged victims are music bloggers, one of the most self-dramatizing and attention-whorish categories of people on earth -- yet these particular bloggers might have a legitimate complaint and might deserve support. You have to take each case on its merits, and you have to withhold help and publicity from attention whores so you can afford to give it to people who have been legitimately wronged.
Somehow, I don't think a few hundred regular posters and a few thousand regular readers on slashdot will do what over 170 governments to date have been unable to do. But I am open to any argument on how to go after the top fifty thousand major censors in the world utilizing the power of... keystrokes.
Your fatalism here is out of step with your eagerness for action elsewhere. Plus, why would you expect governments to go after censors? Governments in many cases are the censors, and when the censors are private entities, they are usually acting within their legal rights, so the government rarely helps. It does take keystrokes, or to put it another way, words. The chattering classes don't change things directly by their chatter, but through their chatter (or keystrokes -- maybe we should call them the "clattering classes") they decide how to wield their real power -- voting and consumption.
Nothing would make front page of Slashdot if we had to wait for all the facts to come in... Because nobody would read slashdot. Part of why slashdot is popular and exists is because it provides information quickly, not necessarily perfectly.
Point taken. I could go either way, but it seems at this point they need the attention of people who can help them investigate, so later the Slashdot headline wouldn't have to be phrased in the form of a question. It would help focus the conversation a bit ;-)
Whether Google is censoring or not is irrelevant. What matters is whether anyone fights back.
I'm confused. Fighting back, supporting those who fight back, and bypassing censorship require knowing when censorship happens and who is responsible for it. By that reasoning, it's hard to see how it's irrelevant whether Google is censoring or not.
"Please stop." Please stop sharing information and doing collective investigation about censorship? Just fight back randomly against... everybody? Even those who don't censor? Work hard to find alternative means of distribution for... all speech? Even the stuff that hasn't been censored?
It seems more constructive to focus efforts on actual censors and instances of actual censorship. Hence, discussions like this are important and relevant. The facts have to be established before anyone knows what action to take. Whether this particular discussion should have made the front page of Slashdot before the facts were better established is another question (and IMHO the answer is "no.")
OpenOffice was big and slow long before it accumulated a nontrivial amount of Java code. The OpenOffice wiki lists exactly which functionality depends on the JRE. I don't see anything performance-critical in there. (Oh, and how did I know that? Because I've seen your argument debunked so many times on Slashdot it isn't even funny.)
As for Eclipse, I really don't understand. I have used Eclipse to write Eclipse RCP apps, and it's pretty miraculous the way it handles its own source code -- thousands of source files in many dozens of packages. If you compare IDEs by how quickly they pop up the "Print..." or "Save As..." dialogs, then Eclipse might rank near the bottom, but on large projects, I worry more about the performance hit of navigating, compiling, searching, and refactoring thousands of files. Eclipse does very well by those standards.
Eclipse support for C++ sucks ass compared to its Java support, though. If you tried developing C++ code in Eclipse then I'm sure it disappointed, but the problem there is not Java but the fact that C++ is not a big development priority for Eclipse.
Python doesn't do inclusive ranges?
It's quite handy for zero-based indexing. It's also convenient for splitting a big list into a bunch of little ones:
[a, b) = [a, a1) union [a1, a2) union [a2, a3) union [a3, b)
That approach makes sense for small jobs, but for projects that take more than (say) two months, it makes more sense to choose a roughly suitable language, even if your proficiency is lower.
Also, for any code that isn't throwaway code, you have to assume that some unknown person will eventually inherit and maintain your code. Under that assumption, it's more important for the language to be appropriate for the task than for the language to be convenient for the initial programmer. You wouldn't want to inherit a bunch of string parsing code written in Fortran, would you? At least choose a roughly suitable language! Even the best imaginable regex library for C has to be relatively crappy (measured by the readability and correctness of code that uses it) just because of the limitations of the language.
Now, I personally detest Perl and am pretty good with C++, but if somebody proposed writing a string parsing program in C++, I would tell them to use whatever non-dead scripting language they know, even if it's Perl, and if they don't know one yet, for God's sake pick one and learn it -- even if it's Perl!
Ruby is meant to be more comfortable and expressive in the hands of a programmer than Python. That means more power and more elegance, but also less regularity, more features, and more emphasis on conciseness instead of readability and learnability. (Python is surprisingly readable for non-Python programmers, which I have found handy more than once.)
Personally, I use Python at work because I'm terrible at remembering linguistic features and syntax. At work almost every neuron in my brain is devoted to C++, so for everything else I need a nice, simple, even stupidly simple language that complements C++. Plus if someone inherits my Python code and says *gasp* "But I don't know Python!" I can honestly say, "Don't worry, you have nothing to worry about. You can learn it in a couple of days."
People tell me Ruby is more natural and expressive, and I believe them, but if Python ever lets me down I'm skipping straight to the Red Pill, aka Lisp, which I have enjoyed recreationally on occasion. (I keep some spare neurons for myself for fun. Don't tell my boss.)
I think this thing may be targeted at the Amish. Otherwise it would just plug itself into the nearest 110V wall socket.
In this case, the KDE team was clear that what the .0 meant was "API stable; will eat babies." It wasn't a huge secret, they plastered it all over the internet.
Well, let's see: http://kde.org/announcements/4.0/ Or check out the first Slashdot story. Unless you actually read through the comments, you'll never know. And isn't it the LEAST interested people who needed to know? They managed to warn everyone who was deeply interested in KDE4, when they really needed to reach and warn the casual users who ended up thinking, "Neat, it's finally here! I'll try it as soon as my distro makes it an option."
OSS is a big world, and nobody follows alls the news about projects they're only marginally interested in. Linus Torvalds was evidently a casual user of KDE who did not follow the news obsessively enough to have the correct, informed expectations of KDE 4.0 and 4.1.
And even if you're an OSS news junky, you got to read things like this on osnews.com:
KDE 4.0 is the first release of "KDE 4", but take note that the developers have clearly stated that KDE 4.0 is not KDE 4, but more of a base release with all the underlying systems ready to go, but with still a lot of work to be done on the user-visible side.
"KDE 4.0 is not KDE 4." Um, at that point they must have known that they were sending mixed, confusing messages. They could have used a different label for the release. Obviously they wanted broader exposure and credit for making a point-oh release. They got both, and they got the backlash.
"Early adopting users" is a relative term. Linux is getting more mainstream attention, and we should expect the language to change accordingly. KDE is a Linux desktop that intends to be usable for mainstream users. So anything they say about "early adopters" or "end users" can be interpreted in a bunch of different ways. I'm an "end user" by Slashdot standards but an "early adopter" by mainstream standards -- I figured I would be able to make 4.0 my default desktop at the expense of a few hours spent Googling and reading forum posts. It turned out to be a lot worse than that.
"Missing features" is pretty vague, too.
In contrast to that ambiguity, "this is the 4.0 release" is pretty clear, at least in the open-source world. Has the OSS world decided mainstream acceptance requires that .0 has to be a crapfest, and .2 should be the first usable version? I think OSS should be selective about adopting commercial software practices ;-)