This kind of criticism has been popping up repeatedly regarding Android. Most of these reports are speculative and seem to be ignoring the facts, which are that:
1) There are hardly any vendor specific Android SDKs, everybody gets their SDK from Google. Apparently this is not causing any problems with respect to compatibility between the included emulator and device compatibility. If this was an issue, people would be downloading vendor specific APIs to work around the problem. As it is, they are not. It's a non issue. It just works. 2) Most speculative pieces like the hardly original one cited here on compatibility come without any concrete examples whatsoever: which popular Android applications are actually problematic? Where are the hordes of disgruntled users? What's the actual technical analysis of the underlying causes? Where are the device specific applications? 3) Barring documented differences, the Android platform is actually backwards compatible. So if you want to target Android 1.6-2.1, don't use any features introduced after 1.6 or make the use of those features optional. 4) So far the first available Android device, i.e. the G1, has been updated to the latest Android version. Not right away of course, but the fact is that most Android devices in the market are 1.6 or newer either because they shipped like that or because they have been upgraded at some point. 5) The predominant application development platform on the Android phone is Java. What you think you might know about compatibility and native platforms simply does not apply to a proper Java platform covered in unit tests like Android. By and large backwards compatibility is a complete non issue. See 2. If you have evidence suggesting otherwise, share it. If it's not backwards compatible, your unit tests fail and you fix the problem. It's that simple. 6) Most other vendors address this issue by not licensing their platforms to others (e.g. RIM) and shipping only a handful of devices (Apple) or regularly breaking compatibility (MS). Given the competition, Google is actually doing pretty decent shipping a platform that runs on dozens of devices from dozens of vendors. Windows mobile is the closest thing in terms of breadth and we all love windows mobile for its excellent compatibility track record right? (NOT:-) ). The failure of other vendors to address this issue is what has been driving Android growth in the past year. 7) Of course there are bad devices out there and vendors with bad software update policies. SE shipping a 1.6 device at this point in time is illustrative of their poor strategy. Their inability to get this device out of the door is testimony to their incompetence. Their declining market share is well deserved. Don't blame Google for that though. 8) The practice of forking code, which is what some vendors do, is bad for compatibility and time to market. This is true for any piece of software. If you are going to get an Android device, make sure it is running Android 2.x and that the vendor in question has a track record of supporting their devices in the field with updates. Extensive vendor or operator specific customizations mean significant delays between getting updates on your device and increased dependence on a probably not so competent development team.
What do you mean small subset, you can compile and install KDE and x.org on Cygwin. Pointless I agree, but most common place unix commandline stuff compiles and works on cygwin. I used to depend on cygwin to make life a bit more tolerable when I was still depending on windows laptops for development. There's something called puttycyg which is a fork of putty with some cygwin stuff compiled in that really improves the terminal experience (bash in a dos window kind of sucks).
I never noticed any performance issues. But then I don't do much performance critical work on the commandline. A few simple greps, ls and wc commands and the odd bash script to automate some stuff.
Well, Maemo is essentially a Debian derivative with the fully functional debian package management tools installed and configured to be used with Nokia software repositories for over the air apt-get updates & upgrades (i.e. no need to flash the device with new firmware, you'll get updates as they are made available). You can install a package from the officially supported (i.e. no need for hacks to accomplish this) list of packages to get a root shell after which you can modify sources.list to e.g. add one of the several repositories for free (OSS) goodies or even your own repository (which is really nice if you are developing for the device).
This is right now the only device that is truly open to modification and usable as an actual phone at the same time. There are many linux phones on the market but most are either intended for developers and barely functional or intended for end users and completely locked down (e.g. pretty much any Android phone). The N900 is not locked down, comes with official support to get root access, excellent linux based SDK, an excellent mozilla based browser, excellent multimedia and multitasking support, and it is a pretty good phone too.
disclaimer: I work for Nokia but just check the many independent reviewers for some more or less unanimously shared enthusiasm about what this phone can do.
That's just another way of saying sql databases are a poor match for the requirements big websites face. SQL databases used at scale almost always throw characteristic features like transactions, joins, or even ACID out of the window in order to scale. Once you start doing that, SQL databases just become a really complicated way to store stuff. The one database that is really popular on big websites is mysql, which started out its popularity as a non transactional database. While most common features have been slapped on since, the proper way to use mysql at large scale still involves not relying on those.The way sites like facebook, ebay, etc. use it is as a dumb key-value store. Apparently, Amazon does not use database transactions. That's pretty steep for a billion dollar+ revenue ecommerce site that handles millions of financial transactions per day. I'm pretty sure they'd use database transactions if it was feasible to do so. Instead they handle transactions at the application level.
So the problem is not APIs but the fact that the underlying technology can't live up to the requirements. Never mind what is possible in theory because that's not worth shit in practice. Now there are several non sql storage systems under development with different designs that are designed from the ground up to be scalable and have all sorts of desirable qualities regarding data integrity and a growing number of people relying on them in real world situations.
You might make the case that the N900 already has the better hardware when you compare it to the iphone. And for all people dismissing Nokia as just a hardware company, there's tons of non trivial Nokia IPR in the software stack as well (not all OSS admittedly), that provides lots of advantages in the performance or energy efficiency domain; excellent multimedia support (something a lot of smart phones are really bad at), hardware acceleration, etc. Essentially most vendors ship different combinations of chips coming from a very small range of companies so from that point of view it doesn't really matter what you buy. The software on top makes all the difference and the immaturity of newer platforms such as Android can be a real deal breaker when it comes to e.g. battery life, multimedia support, support for peripherals, etc. There's a difference between running linux on a phone and running it well. Nokia has invested heavily in the latter and employs masses of people specialized in tweaking hardware and software to get the most out of the hardware.
But the real beauty of the N900 for the slashdot crowd is simply the fact that it doesn't require hacks or cracks: Nokia actively supports & encourages hackers with features, open source developer tools, websites, documentation, sponsoring, etc. Google does that to some extent with Android but the OS is off limits for normal users. Apple actively tries to stop people from bypassing the appstore and is pretty hostile to attempts to modify the OS in ways they don't like. Forget about other platforms. Palm technically uses linux but they are still keeping even the javascript + html API they have away from users. It might as well be completely closed source. You wouldn't know the difference.
On the other hand, the OS on the N900 is Debian. Like on Debian, the package manager is configured in/etc/sources.list which is used by dpkg and apt-get, which work just as you would expect on any decent Debian distribution. You have root access, therefore you can modify any file, including sources.list. Much of Ubuntu actually compiles with little or no modification and most of the problems you are likely to encounter relate to the small screen size. All it takes to get to that software is pointing your phone at the appropriate repositories. There was at some point a Nokia sponsored Ubuntu port to ARM even, so there is no lack of stuff that you can install. Including stuff that is pretty pointless on a smart phone (like large parts of KDE). But hey, you can do it! Games, productivity tools, you name it and there probably is some geek out there who managed to get it to build for Maemo. If you can write software and package it as a Debian package and can cross compile it to ARM (using the excellent OSS tooling of course), there's a good chance it will just work.
So, you can modify the device to your liking at a level no other mainstream vendor allows. Having a modifiable Debian linux system with free access to all of the OS on top of what is essentially a very compact touch screen device complete with multiple radios (bluetooth, 3G, wlan), sensors (GPS, motion, light, sound), graphics, dsp, should be enough to make any self respecting geek drool.
Now with the N900 you get all of that, shipped as a fully functional smart phone with all of the features Nokia phones are popular for such as excellent voice quality and phone features, decent battery life (of course with all the radios turned on and video & audio playing none stop, your mileage may vary), great build quality and form factor, good support for bluetooth and other accessories, etc. It doesn't get more open in the current phone market currently and this is still the largest mobile phone manufacturer in the world.
In other words, Nokia is sticking out its neck for you by developing and launching this device & platform while proclaiming it to be the future of Nokia smart phones. It's risking a lot here because there are lots of parties in the market that are in the business o
That's the whole problem. All the experts are working for the browser vendors. The W3C never had any business overriding them. Css3 will never happen (standardized & widely implemented). But of course the relevant bits have long been implemented and now those await standardization. It would be nice if w3c bureaucracy could catch up here.
Basically what's wrong here is that after a agile start in the nineties, w3c turned into yet another standards organ. Essentially, for most of the past ten years they've done nothing relevant. Most of the good stuff on the web today basically bypassed their processes (AJAX, HTML5, javascript, DOM). At some point XHTML was hijacked by the Semantic Web crowd. This was essentially given a well deserved neck shot today. They never produced standards or products worth reporting here. Meanwhile, browser vendors had to organize outside the W3C to get some progress going. Current HTML5 is the result of that. Anything else ongoing in W3C is pretty much not relevant (unless you are part of the Semantic Web crowd). Css3 is a good example of why standardize first and implement later is a bad idea.
I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.
Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.
So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.
One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.
Yes of course you are right. And more recently we actually have languages with coherent and consistent behavior across implementations (somewhat of a novelty, just look at C implementations). There's several Ruby interpreters that run the Rails framework now. The fastest one (or so it is claimed often) is JRuby, which runs on top of the Java virtual machine, which has has quite many implementations on a wide variety of hardware optimized for running on e.g. embedded hardware or on CPUs with thousands of cores and impressive levels of compatibility given these differences. So saying language X is faster than language Y is a quite meaningless statement these days. Faster on what, and under what conditions and at what required level of stability, and with what kind of benchmark? Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.
Most C programmers believe it is the closest thing to native aside from assembler. Probably correct if you ignore 40 years of progress in the hardware world but downright naive in light of modern day X86 processors. Technically x86 is not a native instruction set anymore but a virtual machine language that happens to have an in hardware translation to the 'real' instruction set. Like all such translations, it comes at a cost of lost flexibility, and indeed performance. But it is worth avoiding having to rewrite all those pesky compilers. So rather than shatter the assumptions C programmers make, they actually support them by sacrificing transistors. The only real difference between Java and C execution model (aside from better defined semantics in Java) is that Java does the translation in software, at run-time, taking into account performance characteristics of both the running program and the underlying hardware. That in a nutshell is why the LLVM project exists to do the same for C programs (and indeed many other languages, including Java).
Of course you have to take into account the levels of abstraction and indirection provided in application frameworks as well. Those come at a cost and that cost is typically high in scripting languages (but you get so much in return). Java is often unfairly compared to C. I say unfairly here because it is usually a comparison of application frameworks rather than the language implementation. Java is in 'laboratory' conditions quite fast, even comparable to C and applies all the same performance optimizations (and then some). Except, nobody programs Java that way (except some dude at work who managed to produce the suckiest Java class ever, different story) . Similarly, C mostly lacks the rich frameworks that are common in the Java world. Transcode a C program to Java and you end up with a code base that is still pretty fast (e.g. quake 2 has a Java port). Stupid people in both camps believe that it is an either-or type decision between the two and that it is somehow inherent to the language what you end up with. Clever engineers know that 95% of their code is not performance critical at all (i.e. cpu idling most of the time), and that it makes a hell of a lot of sense to do whatever is necessary to get that 5% performing as best as possible if the cost in terms of stability, productivity, security, portability, etc is low enough. That's why server-side c is not a commonly required job skill.
That's why Apple used the llvm platform to port Mac OS X to mobile phones and why Google chose to implement a heavily customized Java vm on top of familiar C/C++ components to emulate their success. Good engineers know when to choose what. Both iphone and android are excellent achievements that move beyond the stupid status quo of wondering which language is better.
... unless you narrow it down to Mathematics, Physics and Computer science departments of course. BTW. I fully sympathize with those inclined to defining it as such:-).
All that stuff about typography is bullshit. The only real reason latex is used there is formulas, which is a niche feature that lacks relevance outside the exact sciences. You might find the occasional sociologist, anthropologist, biologist, etc. using Latex but by and large they are anomalies in a population that is mostly completely ignorant of the 'joys' of compiling and debugging your tables, references, and what not and giving up on the many comforts that come with a decent word processor, none of which seem to be particularly well cared for by your average programmer's editor (which tend to optimized for different purposes).
Now there will be a ton of uber geeks itching to mention a feature or two that is their biggest reason for sticking to latex but the truth is that this crowd is simultaneously to conservative to switch to anything else and too uninvolved in OSS to actually step forward and fix one of the many OSS word replacements so that it can do whatever it is that makes Latex work for them. Apparently, nobody that cares enough to recognize the many flaws of latex related workflows is competent or willing to step forward and fix them. Guilty as charged myself as well (obligatory disclaimer for sitting on my ass here).
Open Office? Crappy compared to both MS Office and Latex. When given the choice, I choose to use something else (seem to default to word, but just because it is easy). Latex, if I have to. Abi word: niche product that doesn't do most of the things a scientist would need. Great if ms write/wordpad (same thing really) would have done the job as well. What else is there? K-office. Nice, ambitious, and notoriously nearly done but not actually usable ever since people started working on it (10-12 years ago?).
Consequently, we're stuck with a software system put together by a nearly retired professor and author of excellent books on computer science who peeked with his career in the seventies, i.e. some 30-40 years ago, that has had no updates worth writing home about since before I started studying computer science in the mid nineties. Nothing against Donald Knuth (great achievements and would have been honered to have been taught by this man). But shit, the world has moved on. Is latex really the best mankind can do when it comes to writing articles and thesises?
Export controls are largely ineffective and easily bypassed with proxies and intermediate partners. I've heard in several separate cases that people working for multinationals in Iran simply use a middleman to get their hands on any equipment they need. They simply 'advice' their customers that in order to operate foo, they would need x units of component bar which they are sadly unable to deliver due to export restrictions and basically bar 'magically' appears on site when needed, no questions asked.
Basic problem is that the US exports to most countries in the world and exporting from those countries to those to which it doesn't want to export is basically not controlled at all (except by local legislation in e.g. NATO member states). So all you need is a willing middleman in any country the US can export to. The middleman is not in US jurisdiction and under no obligation to even inform US trading partners of intent to export. Likewise US trading partners have no interest whatsoever in knowing what happens to their stuff after they ship it.
Naturally, most US companies maintain good & extensive relations with such middlemen providing them with support, logistics, etc.
On most windows PCs you are better off maxing out the memory on the motherboard (which you can do quite cheaply) and telling windows to never ever waste your time copying bits back and forth between the paging file and RAM (which it will happily do for no good reason at all otherwise). Think PC with 1.5GB, 1 GB free and the damn OS swapping your applications to disk so that each alt tab results in lots of disk activity, especially painful on otherwise fast and capable laptops with slow disks. 1.5 GB is plenty for Java development using Eclipse and running Firefox and a few office applications all at the same time.
It depends on your usage pattern but I've done this on a laptop with 1.5 GB and got a huge performance boost. The flipside is that the OS will get a bit more rude when you run out of memory. But on the other hand that saves you some time as well because the alternative is that it gets very very slow. Just keep an eye on your memory usage and close some applications when you are closing in on the upper limit.
Macs are different. I have 4 GB in mine and the OS is generally very well behaved with the page file. I guess with linux it depends. Basically if you run a server, a page file is a waste of time (either you have enough ram or you don't, when you don't you are in trouble).
It's going to be open source apparently, so if it is really evil, people will point that out based on the facts rather than uninformed opinion. If you don't like what you see, you can fix it. Doing evil stuff would actually be quite stupid from a marketing perspective because their offerings are just about the most scrutinized in the world so they don't stand any chance whatsoever of getting away with it.
Besides, they're perfectionists and there's a lot to be desired with current browsers, especially if you know anything about the technology involved. Which of course they do. Faster Javascript, separate processes for tabs, sandboxed plugins. Bring it on I'd say!
If you read the strips carefully, you'll see Ben Goodger is featured. He's one of the guys that created Firefox a few years ago (the guy actually).
Anyway, Google rarely bets on one horse and they just extended Mozilla funding until 2011 as well. So they're not only putting their full support behind Mozilla, they've been doing so for years.
I'd say that given what Google has done for ordinary browser users in the past, they deserve quite a bit more credit than you give them here. From my point of view Google is doing all the right things here both for their own business as well as for end users.
Dito, though I haven't found my way the big U yet. The big trilogy took me a whopping two and a half years to complete with me putting off reading parts two and three for long periods of time. I basically read part three in increasingly longer bursts spread over nearly half a year until finally racing through the last four hundred pages in two days. Basically it is a lot of information to digest and you need a pretty good overview of all the events to enjoy the wacky plot twists and elaborate digressions. All things together, it would take me some courage (and plenty of time) to pick it up again but I am glad I read the three books cover to cover in the end.
BTW. for the real fans, there's a great 56 page article from 1996 on Wired by Neal Stephenson about a trip around the world he did in the mid nineties to explore the wonderful world of the fiber optic cable laying industry. Great read and sort of a study for the Cryptonomicon. I guess for Stephenson this counts as a short story though any other author would have no problem to publish it as a short novel.
True, perl continues to be somewhat popular as one of the many unix scripting languages but hardly the most fashionable one. Lets just say it's not an obvious pick in that domain anymore either. Python seems to have pretty much displaced it there. But it would be a stretch to call it a legacy language there.
Anyway, the reason I singled out web applications is because that is pretty much the largest application domain for scripting these days and much of the development effort around scripting languages seems to be focused on that. Aside from web apps and unix scripting, perl has not been used for much else.
Perl had a brief period where it was relatively popular in the mid nineties before php came along and later things like ruby on rails happened. Basically it filled a void between the moment cgi scripting started to get supported on web servers and the moment the first web development oriented tools and languages started to appear (servlets 1997, asp a bit earlier, etc.)
After that, it has remained relatively impopular/obscure language with few/no obvious advantages over other languages and quite a bit of problems. Awkward syntax (yes it's an opinion but one shared by a lot of people who don't use perl), messy language semantics and unimpressive interpreter performance don't help of course. In all fairness, most scripting languages suffer from the last two problems.
So, I don't think it would make sense to pick it as a language for a new web application project unless you happen to have legacy perl code to integrate. That makes it a legacy language.
I think you are both wrong. The issue here is not the algorithms but how you combine them to do the right things. This process includes things like generating keys, storing and retrieving them, exchanging them with other parties, etc. This is surprisingly difficult to get right if you are not an expert. Many existing cryptography frameworks provide plenty of room for mistakes to be made. A single configuration error can defeat the whole purpose of using encryption. Doing things on a case by case basis only creates multiple opportunities for doing the wrong thing.
All this framework does is provide a reasonable implementation to support a range of common use cases in a more or less fool proof way. It reduces the amount of decisions that need to be taken by a programmer and that reduces the amount of room for mistakes. In cryptography, default settings are good: you rely on proven algorithmic strength & best practices and not on obscurity. These breaking down is a lot less likely than you making a mistake.
I've looked for alternatives to the sadly obsolete Framemaker and have come up with nothing. Word sucks. OpenOffice sucks more (no proper cross refs and the bibliography manager is a bad joke). Most other word processors lack features, stability or both or are ms write clones pretending to be ms word clones. I've even resorted to the retarded edit compile debug cycle for doing papers in latex again lately. It sucks but at least it produces results reliably.
I think making a desktop application for document editing these days is not necessarily the most natural thing to do anymore.
If you check out this techtalk, http://www.youtube.com/watch?v=vcXUrNSvjhU You will see a nice presentation by CSS guru HÃ¥kon Lie and Michael Day on how XML/HTML + CSS can be used to produce professional quality books in PDF format suitable to go straight to the printer using a (commercial) print oriented CSS render engine. It's not quite to the level of Tex yet but should be more than OK for most purposes.
If you combine this with a nice content management system, you should be able to come up with a quite nice set of tooling. You could export to various formats, including docbook, latex, pdf, and even word if you have to. In the content management system you could support collaborative editing, versioning, commenting, fine grained security, etc. quite easily. There's no reason whatsoever why content management systems would not be able to handle complex document structures.
I'm thinking google docs for framemaker refugees. I think it could be done and could provide great value. People would migrate from word and never look back. Nothing like this exists today as far as I know even though essentially all of the required components exist in some form today. Something like Drupal could provide a great start with a flexible node based content model and loads of other content management features. Alternatively something based on the Java Content Repository JSR could be used. Ideally the tool chain would rely on open standards so that it could be easily customized for different tasks. Existing office file format "standards" are hopelessly mixing presentation, content and legacy features so I don't really consider these to be relevant here.
It's popular to be against patents here on slashdot but most of the discussion is unfortunately limited to very simplistic black and white type reasoning where people use legal terms they barely understand. Quite frankly, most people here seem to have no clue about what they are actually against / in favor of. What is a software patent and what is not a software patent is very murky in a legal sense and quite hard to explain. Quite many patents related to software systems are actually phrased as traditional patents about devices performing certain functionality in very general broad terms. In other words, they are not software patents at all and you can get them registered outside the US (provided there is enough novelty).
The problem is not so much that there are software patents, but that there are many trivial patents for which the prior art research leaves a lot to be desired and for which the claims are covering a lot of existing systems. Challenging these is difficult, time consuming and expensive. Patents that are actually software patents or method patents are generally pretty weak to begin with. It means the patent lawyer wasn't able to phrase the invention in more traditional patent terminology (and they are really good at this). Having them is one thing, enforcing them is another.
Some lawyers & institutions pondering how to tweak definitions, interpretations, etc means nothing until laws are actually changed and until court cases (re)define interpretations of those laws. We are talking about a very lengthy process that is going to be very political. Decisions will be challenged endlessly because the stakes are very high. A decade is nothing here. Even then the impact is probably going to be very limited. No way, that many thousands of IBM, Sun, Microsoft, etc. patents are suddenly invalidated. That represents billions of dollars of investment for these companies (R&D + legal fees). At best it might get slightly easier to challenge some of the more obvious patents.
That's probably a good thing long term and there seems to be a lot of demand from big corporations for this due to the fact that they are under constant attack from small companies owning bullshit patents. But meanwhile the amount of patents registered will likely continue to grow.
For something that doesn't matter, it is mentioned an awful lot on a site that still claims to focus on "stuff that matters". Little pokes at Java have been in fashion for a long time here. I think Java is still topping the list of languages discussed on this site and has long done so. No thread about Java is complete without these little pokes.
So kind of on topic to do it right in the summary. Bored editor puts some extra flamebait in summary of an obviously pointless article and the accompanying stupid rhetorical question. What's new?
UML is mostly used in a informal fashion as a way to illustrate text outlining/documenting a design. As such it can be useful since it gives engineers a concise vocabulary to discuss things on a whiteboard or piece of paper. As such it has somewhat displaced older notations and I actually like it. One of my favorite tools is an obscure one called umlet that does exactly what I need it to do: generate diagrams from very concise pseudo code.
What is dead, or rather was never alive, is UML tooling as a silver bullet to fix bad design, incompetent consultants, magic please generate my application tools, etc. Rational Rose is one of the most successful scams in our industry. They sell lots of tools, licenses, certification and consultancy to companies that think their architecture and design problems can be bought off. I heard a talk by Ivar Jacobson once where he joked that he was happy that people were buying his books (on e.g. Rational Unified Process) but regretted that they didn't bother reading them.
I've been in a number of companies and I've never seen any effective use of UML related tooling beyond the annotate boring word documents and power point slides with pointless diagrams stage. We all know the diagrams where trivial classes with a bunch of setters and getters get nice sequence diagrams and use case diagrams and the state diagram or sequence diagram for the poorly designed 3000 lines long very complex class is conveniently omitted.
My best example here is very simple: try find UML diagrams of eclipse EMF and related infrastructure for many UML tools. Hint, you won't find much to write home about. This is extremely complicated software and UML just isn't good enough for it. The experts on this matter are voting with their feet. UML tool designers don't eat their own dog food when it comes to their own software. So why should you? Come to think of it, I don't know of any open source projects where UML is used extensively. I know of a few with bullshit design wikis sporting a few useless class diagrams though. I also know of quite many that produce UML tooling. But I know of exactly 0 projects that use UML tooling as intended.
Having a tool point out your errors and mistakes can be quite useful in learning how not to make those mistakes. Basically that improves the quality of programmer output. How is that a bad thing?
Regarding the rest of your comments. That is called progress. It's the reason that you don't have to chase your dinner with a club to kill it before you make some fire with two rocks. I can imagine several reasons why it could be useful to know how to actually do that but I'm fine with the pizza boy delivering my dinner.
C is just one of the many things in a long line of inventions. Before programming languages were invented you actually had to be intimately familiar with how the machine in front of you (or rather in the huge room you were in) processed the bits you manually fed to it and how to interpret what came back. Many such skills were lost when people started to use compilers. Most programmers today, C or otherwise, have probably only a very limited notion of how their own PC processes their instructions. C was designed for a computer architecture that is vastly more simplistic than what is used today. Most C programmers think they understand their CPU because they think they know how their C code maps 1 to 1 to processor instructions. That's naive at best these days. Do you know how to fix your CPU architecture when it breaks? Do you think that's a problem for doing your job?
To fix the JVM in case of bugs in the bytecode compiler you'd actually need those skills. That's why it's called a virtual machine. C is just a means to mediate between the machine level architecture and the virtual machine level architecture.
Better is a point of view. The market reflects the point of view of the people in it, voting with their wallet.
Support, testing, user familiarity & general usability, hardware support. It's all part of the product and for ordinary users can be the difference of having a working PC or a useless brick. Also these require massive investment to get to the level Microsoft is delivering for hundreds of millions of users. Linux is behind in all those non functional areas.
I never said windows was better technically. I actually believe, like you, that it isn't although on the other hand I think Linux technical advantages are mostly irrelevant for users whereas its non technical flaws aren't. Linux is quite good if you know what you are doing which is why I don't recommend bothering with it to people who don't. On the other hand, if you just want to plug in a headset + webcam and chat a bit with your mom over skype... Well, good luck making your mom get that to work on Ubuntu on the other end of a phone (not a hypothetical situation in my case, and yes she managed to do it in windows).
I think Linux is doing quite well in the market given its flaws. The market tells us that desktop linux is either being used by hobbyists, in very controlled enterprise deployments, or in cheap devices. There is still virtually no demand among normal users. That's progress from just a few years ago and I'm sure it will continue to improve.
Markets are not right or wrong. Just the people that operate in them. It might be that people just don't get it or it might be that the product is not good enough. Anyway, calling that many people idiots is quite a stretch.
> This whole discussion was pointless to begin with. So is posting comments like this. But hey, it's Sunday and I'm bored.
It's always the same people claiming linux is ready for the masses and obviously better than windows. The market has proven them wrong for more than a decade now. Desktop linux is mainly sold as a cheaper alternative to windows, not as a better one. The main competition now is in the very low end of the market where windows is too expensive for vendors to be able to compete with their linux shipping competitors. The experience is limited & mediocre but the price compensates.
Slashdot Mirror
This kind of criticism has been popping up repeatedly regarding Android. Most of these reports are speculative and seem to be ignoring the facts, which are that:
1) There are hardly any vendor specific Android SDKs, everybody gets their SDK from Google. Apparently this is not causing any problems with respect to compatibility between the included emulator and device compatibility. If this was an issue, people would be downloading vendor specific APIs to work around the problem. As it is, they are not. It's a non issue. It just works. :-) ). The failure of other vendors to address this issue is what has been driving Android growth in the past year.
2) Most speculative pieces like the hardly original one cited here on compatibility come without any concrete examples whatsoever: which popular Android applications are actually problematic? Where are the hordes of disgruntled users? What's the actual technical analysis of the underlying causes? Where are the device specific applications?
3) Barring documented differences, the Android platform is actually backwards compatible. So if you want to target Android 1.6-2.1, don't use any features introduced after 1.6 or make the use of those features optional.
4) So far the first available Android device, i.e. the G1, has been updated to the latest Android version. Not right away of course, but the fact is that most Android devices in the market are 1.6 or newer either because they shipped like that or because they have been upgraded at some point.
5) The predominant application development platform on the Android phone is Java. What you think you might know about compatibility and native platforms simply does not apply to a proper Java platform covered in unit tests like Android. By and large backwards compatibility is a complete non issue. See 2. If you have evidence suggesting otherwise, share it. If it's not backwards compatible, your unit tests fail and you fix the problem. It's that simple.
6) Most other vendors address this issue by not licensing their platforms to others (e.g. RIM) and shipping only a handful of devices (Apple) or regularly breaking compatibility (MS). Given the competition, Google is actually doing pretty decent shipping a platform that runs on dozens of devices from dozens of vendors. Windows mobile is the closest thing in terms of breadth and we all love windows mobile for its excellent compatibility track record right? (NOT
7) Of course there are bad devices out there and vendors with bad software update policies. SE shipping a 1.6 device at this point in time is illustrative of their poor strategy. Their inability to get this device out of the door is testimony to their incompetence. Their declining market share is well deserved. Don't blame Google for that though.
8) The practice of forking code, which is what some vendors do, is bad for compatibility and time to market. This is true for any piece of software. If you are going to get an Android device, make sure it is running Android 2.x and that the vendor in question has a track record of supporting their devices in the field with updates. Extensive vendor or operator specific customizations mean significant delays between getting updates on your device and increased dependence on a probably not so competent development team.
What do you mean small subset, you can compile and install KDE and x.org on Cygwin. Pointless I agree, but most common place unix commandline stuff compiles and works on cygwin. I used to depend on cygwin to make life a bit more tolerable when I was still depending on windows laptops for development. There's something called puttycyg which is a fork of putty with some cygwin stuff compiled in that really improves the terminal experience (bash in a dos window kind of sucks).
I never noticed any performance issues. But then I don't do much performance critical work on the commandline. A few simple greps, ls and wc commands and the odd bash script to automate some stuff.
Well, Maemo is essentially a Debian derivative with the fully functional debian package management tools installed and configured to be used with Nokia software repositories for over the air apt-get updates & upgrades (i.e. no need to flash the device with new firmware, you'll get updates as they are made available). You can install a package from the officially supported (i.e. no need for hacks to accomplish this) list of packages to get a root shell after which you can modify sources.list to e.g. add one of the several repositories for free (OSS) goodies or even your own repository (which is really nice if you are developing for the device).
http://repository.maemo.org/
This is right now the only device that is truly open to modification and usable as an actual phone at the same time. There are many linux phones on the market but most are either intended for developers and barely functional or intended for end users and completely locked down (e.g. pretty much any Android phone). The N900 is not locked down, comes with official support to get root access, excellent linux based SDK, an excellent mozilla based browser, excellent multimedia and multitasking support, and it is a pretty good phone too.
disclaimer: I work for Nokia but just check the many independent reviewers for some more or less unanimously shared enthusiasm about what this phone can do.
That's just another way of saying sql databases are a poor match for the requirements big websites face. SQL databases used at scale almost always throw characteristic features like transactions, joins, or even ACID out of the window in order to scale. Once you start doing that, SQL databases just become a really complicated way to store stuff. The one database that is really popular on big websites is mysql, which started out its popularity as a non transactional database. While most common features have been slapped on since, the proper way to use mysql at large scale still involves not relying on those.The way sites like facebook, ebay, etc. use it is as a dumb key-value store. Apparently, Amazon does not use database transactions. That's pretty steep for a billion dollar+ revenue ecommerce site that handles millions of financial transactions per day. I'm pretty sure they'd use database transactions if it was feasible to do so. Instead they handle transactions at the application level.
So the problem is not APIs but the fact that the underlying technology can't live up to the requirements. Never mind what is possible in theory because that's not worth shit in practice. Now there are several non sql storage systems under development with different designs that are designed from the ground up to be scalable and have all sorts of desirable qualities regarding data integrity and a growing number of people relying on them in real world situations.
You might make the case that the N900 already has the better hardware when you compare it to the iphone. And for all people dismissing Nokia as just a hardware company, there's tons of non trivial Nokia IPR in the software stack as well (not all OSS admittedly), that provides lots of advantages in the performance or energy efficiency domain; excellent multimedia support (something a lot of smart phones are really bad at), hardware acceleration, etc. Essentially most vendors ship different combinations of chips coming from a very small range of companies so from that point of view it doesn't really matter what you buy. The software on top makes all the difference and the immaturity of newer platforms such as Android can be a real deal breaker when it comes to e.g. battery life, multimedia support, support for peripherals, etc. There's a difference between running linux on a phone and running it well. Nokia has invested heavily in the latter and employs masses of people specialized in tweaking hardware and software to get the most out of the hardware.
But the real beauty of the N900 for the slashdot crowd is simply the fact that it doesn't require hacks or cracks: Nokia actively supports & encourages hackers with features, open source developer tools, websites, documentation, sponsoring, etc. Google does that to some extent with Android but the OS is off limits for normal users. Apple actively tries to stop people from bypassing the appstore and is pretty hostile to attempts to modify the OS in ways they don't like. Forget about other platforms. Palm technically uses linux but they are still keeping even the javascript + html API they have away from users. It might as well be completely closed source. You wouldn't know the difference.
On the other hand, the OS on the N900 is Debian. Like on Debian, the package manager is configured in /etc/sources.list which is used by dpkg and apt-get, which work just as you would expect on any decent Debian distribution. You have root access, therefore you can modify any file, including sources.list. Much of Ubuntu actually compiles with little or no modification and most of the problems you are likely to encounter relate to the small screen size. All it takes to get to that software is pointing your phone at the appropriate repositories. There was at some point a Nokia sponsored Ubuntu port to ARM even, so there is no lack of stuff that you can install. Including stuff that is pretty pointless on a smart phone (like large parts of KDE). But hey, you can do it! Games, productivity tools, you name it and there probably is some geek out there who managed to get it to build for Maemo. If you can write software and package it as a Debian package and can cross compile it to ARM (using the excellent OSS tooling of course), there's a good chance it will just work.
So, you can modify the device to your liking at a level no other mainstream vendor allows. Having a modifiable Debian linux system with free access to all of the OS on top of what is essentially a very compact touch screen device complete with multiple radios (bluetooth, 3G, wlan), sensors (GPS, motion, light, sound), graphics, dsp, should be enough to make any self respecting geek drool.
Now with the N900 you get all of that, shipped as a fully functional smart phone with all of the features Nokia phones are popular for such as excellent voice quality and phone features, decent battery life (of course with all the radios turned on and video & audio playing none stop, your mileage may vary), great build quality and form factor, good support for bluetooth and other accessories, etc. It doesn't get more open in the current phone market currently and this is still the largest mobile phone manufacturer in the world.
In other words, Nokia is sticking out its neck for you by developing and launching this device & platform while proclaiming it to be the future of Nokia smart phones. It's risking a lot here because there are lots of parties in the market that are in the business o
That's the whole problem. All the experts are working for the browser vendors. The W3C never had any business overriding them. Css3 will never happen (standardized & widely implemented). But of course the relevant bits have long been implemented and now those await standardization. It would be nice if w3c bureaucracy could catch up here.
Basically what's wrong here is that after a agile start in the nineties, w3c turned into yet another standards organ. Essentially, for most of the past ten years they've done nothing relevant. Most of the good stuff on the web today basically bypassed their processes (AJAX, HTML5, javascript, DOM). At some point XHTML was hijacked by the Semantic Web crowd. This was essentially given a well deserved neck shot today. They never produced standards or products worth reporting here. Meanwhile, browser vendors had to organize outside the W3C to get some progress going. Current HTML5 is the result of that. Anything else ongoing in W3C is pretty much not relevant (unless you are part of the Semantic Web crowd). Css3 is a good example of why standardize first and implement later is a bad idea.
So put the server on your mobile phone (if you have a Nokia): http://mymobilesite.net/. Opera is hardly being original here ...
I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.
Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.
So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.
One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.
Yes of course you are right. And more recently we actually have languages with coherent and consistent behavior across implementations (somewhat of a novelty, just look at C implementations). There's several Ruby interpreters that run the Rails framework now. The fastest one (or so it is claimed often) is JRuby, which runs on top of the Java virtual machine, which has has quite many implementations on a wide variety of hardware optimized for running on e.g. embedded hardware or on CPUs with thousands of cores and impressive levels of compatibility given these differences. So saying language X is faster than language Y is a quite meaningless statement these days. Faster on what, and under what conditions and at what required level of stability, and with what kind of benchmark? Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.
Most C programmers believe it is the closest thing to native aside from assembler. Probably correct if you ignore 40 years of progress in the hardware world but downright naive in light of modern day X86 processors. Technically x86 is not a native instruction set anymore but a virtual machine language that happens to have an in hardware translation to the 'real' instruction set. Like all such translations, it comes at a cost of lost flexibility, and indeed performance. But it is worth avoiding having to rewrite all those pesky compilers. So rather than shatter the assumptions C programmers make, they actually support them by sacrificing transistors. The only real difference between Java and C execution model (aside from better defined semantics in Java) is that Java does the translation in software, at run-time, taking into account performance characteristics of both the running program and the underlying hardware. That in a nutshell is why the LLVM project exists to do the same for C programs (and indeed many other languages, including Java).
Of course you have to take into account the levels of abstraction and indirection provided in application frameworks as well. Those come at a cost and that cost is typically high in scripting languages (but you get so much in return). Java is often unfairly compared to C. I say unfairly here because it is usually a comparison of application frameworks rather than the language implementation. Java is in 'laboratory' conditions quite fast, even comparable to C and applies all the same performance optimizations (and then some). Except, nobody programs Java that way (except some dude at work who managed to produce the suckiest Java class ever, different story) . Similarly, C mostly lacks the rich frameworks that are common in the Java world. Transcode a C program to Java and you end up with a code base that is still pretty fast (e.g. quake 2 has a Java port). Stupid people in both camps believe that it is an either-or type decision between the two and that it is somehow inherent to the language what you end up with. Clever engineers know that 95% of their code is not performance critical at all (i.e. cpu idling most of the time), and that it makes a hell of a lot of sense to do whatever is necessary to get that 5% performing as best as possible if the cost in terms of stability, productivity, security, portability, etc is low enough. That's why server-side c is not a commonly required job skill.
That's why Apple used the llvm platform to port Mac OS X to mobile phones and why Google chose to implement a heavily customized Java vm on top of familiar C/C++ components to emulate their success. Good engineers know when to choose what. Both iphone and android are excellent achievements that move beyond the stupid status quo of wondering which language is better.
... unless you narrow it down to Mathematics, Physics and Computer science departments of course. BTW. I fully sympathize with those inclined to defining it as such :-).
All that stuff about typography is bullshit. The only real reason latex is used there is formulas, which is a niche feature that lacks relevance outside the exact sciences. You might find the occasional sociologist, anthropologist, biologist, etc. using Latex but by and large they are anomalies in a population that is mostly completely ignorant of the 'joys' of compiling and debugging your tables, references, and what not and giving up on the many comforts that come with a decent word processor, none of which seem to be particularly well cared for by your average programmer's editor (which tend to optimized for different purposes).
Now there will be a ton of uber geeks itching to mention a feature or two that is their biggest reason for sticking to latex but the truth is that this crowd is simultaneously to conservative to switch to anything else and too uninvolved in OSS to actually step forward and fix one of the many OSS word replacements so that it can do whatever it is that makes Latex work for them. Apparently, nobody that cares enough to recognize the many flaws of latex related workflows is competent or willing to step forward and fix them. Guilty as charged myself as well (obligatory disclaimer for sitting on my ass here).
Open Office? Crappy compared to both MS Office and Latex. When given the choice, I choose to use something else (seem to default to word, but just because it is easy). Latex, if I have to. Abi word: niche product that doesn't do most of the things a scientist would need. Great if ms write/wordpad (same thing really) would have done the job as well. What else is there? K-office. Nice, ambitious, and notoriously nearly done but not actually usable ever since people started working on it (10-12 years ago?).
Consequently, we're stuck with a software system put together by a nearly retired professor and author of excellent books on computer science who peeked with his career in the seventies, i.e. some 30-40 years ago, that has had no updates worth writing home about since before I started studying computer science in the mid nineties. Nothing against Donald Knuth (great achievements and would have been honered to have been taught by this man). But shit, the world has moved on. Is latex really the best mankind can do when it comes to writing articles and thesises?
Export controls are largely ineffective and easily bypassed with proxies and intermediate partners. I've heard in several separate cases that people working for multinationals in Iran simply use a middleman to get their hands on any equipment they need. They simply 'advice' their customers that in order to operate foo, they would need x units of component bar which they are sadly unable to deliver due to export restrictions and basically bar 'magically' appears on site when needed, no questions asked.
Basic problem is that the US exports to most countries in the world and exporting from those countries to those to which it doesn't want to export is basically not controlled at all (except by local legislation in e.g. NATO member states). So all you need is a willing middleman in any country the US can export to. The middleman is not in US jurisdiction and under no obligation to even inform US trading partners of intent to export. Likewise US trading partners have no interest whatsoever in knowing what happens to their stuff after they ship it.
Naturally, most US companies maintain good & extensive relations with such middlemen providing them with support, logistics, etc.
On most windows PCs you are better off maxing out the memory on the motherboard (which you can do quite cheaply) and telling windows to never ever waste your time copying bits back and forth between the paging file and RAM (which it will happily do for no good reason at all otherwise). Think PC with 1.5GB, 1 GB free and the damn OS swapping your applications to disk so that each alt tab results in lots of disk activity, especially painful on otherwise fast and capable laptops with slow disks. 1.5 GB is plenty for Java development using Eclipse and running Firefox and a few office applications all at the same time.
It depends on your usage pattern but I've done this on a laptop with 1.5 GB and got a huge performance boost. The flipside is that the OS will get a bit more rude when you run out of memory. But on the other hand that saves you some time as well because the alternative is that it gets very very slow. Just keep an eye on your memory usage and close some applications when you are closing in on the upper limit.
Macs are different. I have 4 GB in mine and the OS is generally very well behaved with the page file. I guess with linux it depends. Basically if you run a server, a page file is a waste of time (either you have enough ram or you don't, when you don't you are in trouble).
It's going to be open source apparently, so if it is really evil, people will point that out based on the facts rather than uninformed opinion. If you don't like what you see, you can fix it. Doing evil stuff would actually be quite stupid from a marketing perspective because their offerings are just about the most scrutinized in the world so they don't stand any chance whatsoever of getting away with it.
Besides, they're perfectionists and there's a lot to be desired with current browsers, especially if you know anything about the technology involved. Which of course they do. Faster Javascript, separate processes for tabs, sandboxed plugins. Bring it on I'd say!
If you read the strips carefully, you'll see Ben Goodger is featured. He's one of the guys that created Firefox a few years ago (the guy actually).
Anyway, Google rarely bets on one horse and they just extended Mozilla funding until 2011 as well. So they're not only putting their full support behind Mozilla, they've been doing so for years.
I'd say that given what Google has done for ordinary browser users in the past, they deserve quite a bit more credit than you give them here. From my point of view Google is doing all the right things here both for their own business as well as for end users.
Dito, though I haven't found my way the big U yet. The big trilogy took me a whopping two and a half years to complete with me putting off reading parts two and three for long periods of time. I basically read part three in increasingly longer bursts spread over nearly half a year until finally racing through the last four hundred pages in two days. Basically it is a lot of information to digest and you need a pretty good overview of all the events to enjoy the wacky plot twists and elaborate digressions. All things together, it would take me some courage (and plenty of time) to pick it up again but I am glad I read the three books cover to cover in the end.
BTW. for the real fans, there's a great 56 page article from 1996 on Wired by Neal Stephenson about a trip around the world he did in the mid nineties to explore the wonderful world of the fiber optic cable laying industry. Great read and sort of a study for the Cryptonomicon. I guess for Stephenson this counts as a short story though any other author would have no problem to publish it as a short novel.
http://www.wired.com/wired/archive/4.12/ffglass.html
True, perl continues to be somewhat popular as one of the many unix scripting languages but hardly the most fashionable one. Lets just say it's not an obvious pick in that domain anymore either. Python seems to have pretty much displaced it there. But it would be a stretch to call it a legacy language there.
Anyway, the reason I singled out web applications is because that is pretty much the largest application domain for scripting these days and much of the development effort around scripting languages seems to be focused on that. Aside from web apps and unix scripting, perl has not been used for much else.
Perl had a brief period where it was relatively popular in the mid nineties before php came along and later things like ruby on rails happened. Basically it filled a void between the moment cgi scripting started to get supported on web servers and the moment the first web development oriented tools and languages started to appear (servlets 1997, asp a bit earlier, etc.)
After that, it has remained relatively impopular/obscure language with few/no obvious advantages over other languages and quite a bit of problems. Awkward syntax (yes it's an opinion but one shared by a lot of people who don't use perl), messy language semantics and unimpressive interpreter performance don't help of course. In all fairness, most scripting languages suffer from the last two problems.
So, I don't think it would make sense to pick it as a language for a new web application project unless you happen to have legacy perl code to integrate. That makes it a legacy language.
I think you are both wrong. The issue here is not the algorithms but how you combine them to do the right things. This process includes things like generating keys, storing and retrieving them, exchanging them with other parties, etc. This is surprisingly difficult to get right if you are not an expert. Many existing cryptography frameworks provide plenty of room for mistakes to be made. A single configuration error can defeat the whole purpose of using encryption. Doing things on a case by case basis only creates multiple opportunities for doing the wrong thing.
All this framework does is provide a reasonable implementation to support a range of common use cases in a more or less fool proof way. It reduces the amount of decisions that need to be taken by a programmer and that reduces the amount of room for mistakes. In cryptography, default settings are good: you rely on proven algorithmic strength & best practices and not on obscurity. These breaking down is a lot less likely than you making a mistake.
I've looked for alternatives to the sadly obsolete Framemaker and have come up with nothing. Word sucks. OpenOffice sucks more (no proper cross refs and the bibliography manager is a bad joke). Most other word processors lack features, stability or both or are ms write clones pretending to be ms word clones. I've even resorted to the retarded edit compile debug cycle for doing papers in latex again lately. It sucks but at least it produces results reliably.
I think making a desktop application for document editing these days is not necessarily the most natural thing to do anymore.
If you check out this techtalk,
http://www.youtube.com/watch?v=vcXUrNSvjhU You will see a nice presentation by CSS guru HÃ¥kon Lie and Michael Day on how XML/HTML + CSS can be used to produce professional quality books in PDF format suitable to go straight to the printer using a (commercial) print oriented CSS render engine. It's not quite to the level of Tex yet but should be more than OK for most purposes.
If you combine this with a nice content management system, you should be able to come up with a quite nice set of tooling. You could export to various formats, including docbook, latex, pdf, and even word if you have to. In the content management system you could support collaborative editing, versioning, commenting, fine grained security, etc. quite easily. There's no reason whatsoever why content management systems would not be able to handle complex document structures.
I'm thinking google docs for framemaker refugees. I think it could be done and could provide great value. People would migrate from word and never look back. Nothing like this exists today as far as I know even though essentially all of the required components exist in some form today. Something like Drupal could provide a great start with a flexible node based content model and loads of other content management features. Alternatively something based on the Java Content Repository JSR could be used. Ideally the tool chain would rely on open standards so that it could be easily customized for different tasks. Existing office file format "standards" are hopelessly mixing presentation, content and legacy features so I don't really consider these to be relevant here.
It's popular to be against patents here on slashdot but most of the discussion is unfortunately limited to very simplistic black and white type reasoning where people use legal terms they barely understand. Quite frankly, most people here seem to have no clue about what they are actually against / in favor of. What is a software patent and what is not a software patent is very murky in a legal sense and quite hard to explain. Quite many patents related to software systems are actually phrased as traditional patents about devices performing certain functionality in very general broad terms. In other words, they are not software patents at all and you can get them registered outside the US (provided there is enough novelty).
The problem is not so much that there are software patents, but that there are many trivial patents for which the prior art research leaves a lot to be desired and for which the claims are covering a lot of existing systems. Challenging these is difficult, time consuming and expensive. Patents that are actually software patents or method patents are generally pretty weak to begin with. It means the patent lawyer wasn't able to phrase the invention in more traditional patent terminology (and they are really good at this). Having them is one thing, enforcing them is another.
Some lawyers & institutions pondering how to tweak definitions, interpretations, etc means nothing until laws are actually changed and until court cases (re)define interpretations of those laws. We are talking about a very lengthy process that is going to be very political. Decisions will be challenged endlessly because the stakes are very high. A decade is nothing here. Even then the impact is probably going to be very limited. No way, that many thousands of IBM, Sun, Microsoft, etc. patents are suddenly invalidated. That represents billions of dollars of investment for these companies (R&D + legal fees). At best it might get slightly easier to challenge some of the more obvious patents.
That's probably a good thing long term and there seems to be a lot of demand from big corporations for this due to the fact that they are under constant attack from small companies owning bullshit patents. But meanwhile the amount of patents registered will likely continue to grow.
For something that doesn't matter, it is mentioned an awful lot on a site that still claims to focus on "stuff that matters". Little pokes at Java have been in fashion for a long time here. I think Java is still topping the list of languages discussed on this site and has long done so. No thread about Java is complete without these little pokes.
So kind of on topic to do it right in the summary. Bored editor puts some extra flamebait in summary of an obviously pointless article and the accompanying stupid rhetorical question. What's new?
UML is mostly used in a informal fashion as a way to illustrate text outlining/documenting a design. As such it can be useful since it gives engineers a concise vocabulary to discuss things on a whiteboard or piece of paper. As such it has somewhat displaced older notations and I actually like it. One of my favorite tools is an obscure one called umlet that does exactly what I need it to do: generate diagrams from very concise pseudo code.
What is dead, or rather was never alive, is UML tooling as a silver bullet to fix bad design, incompetent consultants, magic please generate my application tools, etc. Rational Rose is one of the most successful scams in our industry. They sell lots of tools, licenses, certification and consultancy to companies that think their architecture and design problems can be bought off. I heard a talk by Ivar Jacobson once where he joked that he was happy that people were buying his books (on e.g. Rational Unified Process) but regretted that they didn't bother reading them.
I've been in a number of companies and I've never seen any effective use of UML related tooling beyond the annotate boring word documents and power point slides with pointless diagrams stage. We all know the diagrams where trivial classes with a bunch of setters and getters get nice sequence diagrams and use case diagrams and the state diagram or sequence diagram for the poorly designed 3000 lines long very complex class is conveniently omitted.
My best example here is very simple: try find UML diagrams of eclipse EMF and related infrastructure for many UML tools. Hint, you won't find much to write home about. This is extremely complicated software and UML just isn't good enough for it. The experts on this matter are voting with their feet. UML tool designers don't eat their own dog food when it comes to their own software. So why should you? Come to think of it, I don't know of any open source projects where UML is used extensively. I know of a few with bullshit design wikis sporting a few useless class diagrams though. I also know of quite many that produce UML tooling. But I know of exactly 0 projects that use UML tooling as intended.
Having a tool point out your errors and mistakes can be quite useful in learning how not to make those mistakes. Basically that improves the quality of programmer output. How is that a bad thing?
Regarding the rest of your comments. That is called progress. It's the reason that you don't have to chase your dinner with a club to kill it before you make some fire with two rocks. I can imagine several reasons why it could be useful to know how to actually do that but I'm fine with the pizza boy delivering my dinner.
C is just one of the many things in a long line of inventions. Before programming languages were invented you actually had to be intimately familiar with how the machine in front of you (or rather in the huge room you were in) processed the bits you manually fed to it and how to interpret what came back. Many such skills were lost when people started to use compilers. Most programmers today, C or otherwise, have probably only a very limited notion of how their own PC processes their instructions. C was designed for a computer architecture that is vastly more simplistic than what is used today. Most C programmers think they understand their CPU because they think they know how their C code maps 1 to 1 to processor instructions. That's naive at best these days. Do you know how to fix your CPU architecture when it breaks? Do you think that's a problem for doing your job?
To fix the JVM in case of bugs in the bytecode compiler you'd actually need those skills. That's why it's called a virtual machine. C is just a means to mediate between the machine level architecture and the virtual machine level architecture.
Better is a point of view. The market reflects the point of view of the people in it, voting with their wallet.
... Well, good luck making your mom get that to work on Ubuntu on the other end of a phone (not a hypothetical situation in my case, and yes she managed to do it in windows).
Support, testing, user familiarity & general usability, hardware support. It's all part of the product and for ordinary users can be the difference of having a working PC or a useless brick. Also these require massive investment to get to the level Microsoft is delivering for hundreds of millions of users. Linux is behind in all those non functional areas.
I never said windows was better technically. I actually believe, like you, that it isn't although on the other hand I think Linux technical advantages are mostly irrelevant for users whereas its non technical flaws aren't. Linux is quite good if you know what you are doing which is why I don't recommend bothering with it to people who don't. On the other hand, if you just want to plug in a headset + webcam and chat a bit with your mom over skype
I think Linux is doing quite well in the market given its flaws. The market tells us that desktop linux is either being used by hobbyists, in very controlled enterprise deployments, or in cheap devices. There is still virtually no demand among normal users. That's progress from just a few years ago and I'm sure it will continue to improve.
Markets are not right or wrong. Just the people that operate in them. It might be that people just don't get it or it might be that the product is not good enough. Anyway, calling that many people idiots is quite a stretch.
> This whole discussion was pointless to begin with.
So is posting comments like this. But hey, it's Sunday and I'm bored.
It's always the same people claiming linux is ready for the masses and obviously better than windows. The market has proven them wrong for more than a decade now. Desktop linux is mainly sold as a cheaper alternative to windows, not as a better one. The main competition now is in the very low end of the market where windows is too expensive for vendors to be able to compete with their linux shipping competitors. The experience is limited & mediocre but the price compensates.