Something like this http://www.naked.la/, might provide some inspiration for them. Basically this company is launching a beta tonight of a next generation photo editing toolsuite that includes non destructive and resolution & bitdepth independent editing.
It used to be that whenever somebody posted something about a device to slashdot people would jokingly ask if it ran linux. Well, the N770 and N800 were a huge hit with that type of people and the N810 is a very nice upgrade for them. It basically builds on what made those devices so popular in the first place. It's the ultimate hackable linux mobile device. It ships with a big enough touch screen, slidable keyboard, GPS and plenty of juice to run a very wide and growing variety of linux software.
I work at Nokia and although I cannot speak on behalf of my employer (i.e. disclaimer applies) I can say that n770 and n800 have been a huge success in the market. These devices have literally been flying from the shelves since we started shipping them. The thing went absolutely viral despite us not spending that much effort on marketing them initially. The people buying these devices are a mixed bag of people but a substantial amount of them appear to be linux enthusiasts who get from Nokia something that they cannot really get from anyone else currently: a hackable, mobile linux based device with a well supported and really broad development community. Sure there's lots of other mobile linux devices on the market but they pretty much all suck because they've been locked down or because they are unstable or because they have very mediocre hardware. This sounds like it is a handful of people but actually world wide we are talking about a quite large group of people.
For example I interact a lot with researchers in the academic world and for them this series of internet tablets is hugely popular due to fact that it so damn easy for them to implement their research prototypes on them (e.g. ubiquitous computing related research). They're ordering them by the dozens. Of course there are also lots of people who are just pretty happy with the included features and don't actually bother to install extra software. And of course, with the right applications installed, it's also a pretty good enterprise device. Installing those is easy, just use apt-get install or the nice packagemanager or just click on the package in the browser.
As for quality and battery life. I've been using this N800 for several months now. If you use it non stop, it will last you only 4 hours or so. On the other hand unless you use it to watch a movie, you are more likely to just occasionally use it for a few minutes at the time. In that case it can actually last a few days easily. For example, I routinely leave the device on my desk with an open shh connection to it and come back in the morning to find that it is still running fine and has plenty of juice left to make it through another day of testing my software on it. Bottom line is that power management works pretty well on the device. Quality of the software is also pretty good. Major improvements were made to the WLAN in subsequent firmware releases and it is now a lot more stable and power efficient than with earlier releases. Developing on it means I install lots of experimental stuff on the device. Despite this, I can't actually recall the thing resetting or kernel panicking.
To get back to why this niche is important. I can't say why but obviously a lot of companies besides Nokia have become interested in developing n800 like tablets. For example intel seems to bet on this with their maemo derived linux platform. Also the openmoko people are sharing a lot of code with maemo. Apple seems interested in pushing this formfactor a bit further and MS has been pushing pda like phones for years now. There's plenty of tablet like products headed for the market and N810 is some of the better ones currently available.
Windows build is just as large as the apple build. So where did they hide the jre? They might be doing some work arounds for some native issues. The AWT issue sounds like one and I'm aware of Apple having provided eclipse with workarounds for issues in their code like the apple.awt.usingSWT system property on Mac.
Maybe eclipse also puts some replacements for core classes on the boot classpath.
Good to know somebody is working on openjdk on Mac.
1) as a developer I like to stay up to speed with latest developments in my field. Even if I deploy on 1.5, I'll still develop on 1.6. Actually I'm deploying on CDC Java currently. I know many other developers do the same. Of course you need to test on 1.4 as well. Also, deploying your 1.4 code on a 1.6 VM works just fine and buys you some nice performance & manageability advantages (i.e. technically you'd have to be really conservative to not want that). For some server environments, people use what is supported by the vendor rather than what works best, That's one of the major reasons you still find old 1.4 vms (or worse) running in production environments. 1.3 you might also find even though Sun has long stopped supporting it with security patches and is planning to stop support for 1.4 as well. 2) I care because Apple as a technology provider is years behind Sun and I have no other choice than Apple on a Mac. Apple as a deployment option is ok but as a development option it is simply to limiting for me. 3) like all the native stuff that for example integrates swing into quartz; the virtual machine implementation; etc. The problem is that those native bits have compatibility issues with the native SWT bits in eclipse AND that Apple has been very reluctant to do anything about it (see 2). 4) must have been an old version, I think the compatibility issues appeared in the 3.x cycle.
So yes you are right that if 1-4 are a non issue for you now and during the time you will own the mac, you can develop on it. I hope you agree that some level of awareness of these issues would be nice during purchase decisions. In any case for me that is a reason to stay away from Macs. By the time Apple finally ships 1.6, I will be testing on open source 1.7 builds already.
Sorry but that's nonsense as well. Eclipse uses its own compiler (100% Java) for compiling Java which works just fine on pretty much any java virtual machine, including Apple's and a lot of experimental ones (which is a huge advantage of the eclipse compiler). Eclipse does not bundle a custom java virtual machine on any platform, including mac.
Openjdk.net does not provide mac os X builds so don't hope too much. As far as I know there is no work going on for an open source replacement for the closed source apple java implementation.
I'm a Java programmer and I use eclipse. The reason I can't use a Mac is that 1) it still does not support java 1.6 because Apple chooses to bundle new Java versions with new OS versions instead of distributing them separately like the rest of the world does. In practice that means there's up to 1 year or longer (as in this case) before new Java versions find their way onto the Mac. 2) sun does not directly support Mac OS X but leaves the job of porting to Apple, unlike linux, windows and solaris which it does support. 3) If you want to use Sun's OSS Java version on the Mac, you are on your own and will just have to come up with the native mac specific stuff yourself. 4) eclipse has a long history of compatibility issues with Apple's Mac OS X UI Java bindings in their native code for SWT (i.e. this is a C portability issue, not a Java portability issue). It sort of works now but is not quite ideal.
If all of the above is acceptable to you, by all means use a mac for Java development. For me, all of these are unacceptable because I require early access to new Java stuff.
Sun being in charge is not necessarily the problem; the problem is that they lack the competence and vision to bring the necessary changes to OOo and are making it hard to bring in external expertise to fix it. Lets face it, they're a hardware company that also does server software. They sell products to enterprises, not to people. They've never had to deal with end users and they are not very good at it.
The simple reality is that Sun historically has done a less than great job designing and implementing user interfaces for end users. It's true for netbeans; solaris; Java and indeed open office that each of these products has a very long history of quirky, non standard user interfaces that pale to competing products. In all these products progress has been made. Basically solaris now sports a nice Gnome desktop (but they took their time killing their old UI), netbeans is undergowing the zillionth lets "fix the UI" effort, Java did great on the serverside but so far failed to get people enthousiastic on the desktop side (JavaFX being the latest misguided/doomed effort).
The Open office UI looks out of place on any platform. Ugly icons; weird fonts; clumsy stuff like the cross references dialog or the poor excuse for a bibliography manager. Yes you can sort of do most office related stuff in it and for most people that is enough. Sun has been fighting the symptoms for years and they seem to be pretty proud of their work. The truth however is that the overall Sun UI experience is mediocre or adequate at best across their product line.
What open office needs is somebody like Blake Ross to kick out the old UI and do a proper one. Blake and friends rescued the quirky mozilla from the fate that OOo is now facing: being a second choice cheap product that people use for cost rather than quality.
I have about ten years of experience with installing linux distributions (to see what the latest hype/fuss is about) and usually discarding them after the novelty wears off. I'm still a windows guy but my dependencies to win32 specific stuff are fairly limited now. The reason I stick with it is the usual mix of games and a handful of stuff I'd prefer not to be separated from (none of it from MS).
Anyway, I think the review is spot on. Ubuntu has many rough edges and it fixes them by removing the functionality needed to work around them. Basically out of the box, all my hardware was misconfigured (which is excusable for a OS aimed at nerds like me). To fix it I found myself making round trips to the ubuntu forums to figure out which packages to install and what tools to use to finish the job the installer should have done. Specifically, like on so many computers Ubuntu botched the monitor detection (upcoming release should fix that). No big deal but the tool to help you fix it is not installed (probably for usability reasons). Same for alsa config which messed up choosing from three sound cards by redirecting all sound to my usb headset (nice to know it works though) instead of my audigy card which is plugged into a motherboard with yet another sound related chipset. I needed to install a tool to set the default card. Finally, I found the network manager to be a little too obnoxious. I had some issues with a buggy driver for my SIS190 network card. The network manager only got in the way when trying to 'configure' the network, which boils down to editing/etc/network/interfaces and hoping the network manager picks up the changes. I had loads of other problems too. Part of my network trouble caused the installer to hang indefinitely "scanning the mirrors". I had to switch to a console to kill some processes to make it progress. Finally Gparted gave me a pretty good scare at some point by throwing really obscure errors at me for no good reason (made me think my windows partition was gone when it wasn't). In general using the back button in the installer seems a bad idea. Gparted gets awfully confused by that.
Then there is the stuff included in the default install. Rhythmbox crashed a few times on me. That could be one of those pesky mp3 plugins it installed for me. The 3d effects were indeed useless (wise choice to not enable that by default). My first ubuntu update (before installing any software) failed due to a bug in the font server package. Luckily the obscure error produced the right hit in Google along with a bunch of touch commands to give some files the right timestamp. The bug was months old.
I eventually managed to fix everything that ubuntu did wrong and after fixing it is a pretty nice system though not significantly nicer than other distributions I have tried in recent years. So I have to agree here that it is just not for end users. Claiming it is, is just not realistic. Any of the problems I encountered would prove unfixable for novice users. Ubuntu pretends usability by not including notoriously hard to use but essential tools. Unfortunately that means you are on your own when you venture outside the rather narrow set of cases where it manages to configure things automatically. I'm sure there are cases where ubuntu gets everything right and I'm sure it is getting better with each release but from what I've seen it just isn't there yet.
I can understand people not reading every link on a slashdot article they comment on. But if you post the bloody link, is it too much asked to actually RTFA?! It's an article about a column. The actual column is quite interesting.
To add some content, this is about optimal storage for SQL databases in a data warehouse context where there are some interesting products that use something more optimal than the one size fits all solutions currently available from the big RDBMS vendors. The API on top is the same (i.e. SQL and other familiar dataware house APIs), which makes it quite easy to integrate.
Regarding the obsolescence question, one size fits all will be good enough for most for some time to come. Increasingly people are more than happy with lightweight options that are even less efficient on which they slap persistence layers that reduce performance even more just because it allows them to autogenerate all the code that deals with stuffing boring data in some storage. Not having to deal with that makes it irrelevant how the database works and allows you to focus on how you work with the data rather than worrying about tables, rows and ACID properties. Autogenerating code that interacts with the database allows you to do all sorts of interesting things in the generated code and the layers underneath. For example, the hibernate (a popular persistence layer for Java) people have been integrating Apache Lucene, a popular search index product, so that you can index and search your data objects using lucene search queries rather than sql. It's a quite neat solution that adds real value (e.g. fully text searchable product catalogs are dead easy with this).
Column based storage is just an optimization and not really that critical to the applications on top. If you need it, there are some specialized products currently. The author of the column is probably right about such solutions finding their way into mainstream products really soon. At the application level, you'll still be talking good old SQL to the damn thing though.
Re:I Still don't know what GWT is
on
GWT in Action
·
· Score: 1
GWT is a development kit for developing AJAX applications, such as for example GMail. The concept consists of doing all the programming in Java (similar to how you would develop a Java desktop application) and cross compiling the client components to javascript + html. The advantage of this is that you don't have to think about html, javascript, browser-server communication and many other difficult browser issues that most other web developers waste most of their time on (instead of implementing functionality). GWT makes things like interacting with the browser history, back button and other difficult to do stuff dead easy. Basically the toolkit encapsulates all the javascript voodoo that you normally need to do to do this properly & cross browser. Just define all logic as Java code GWT generates the rest. Of course you can also go for a partial approach where you do part of the application using ordinary javascript and html and only do parts of the app in GWT. Basically this allows you to use as much or as little of GWT as you need.
The IDE part is integrated into eclipse and offers all the advanced development features that Java programmers are used to like incremental compilation, refactoring, auto-completion etc. To the developer, GWT looks like just another Java library that builds on all the idioms and patterns they know already. Of course you can debug your application as well either before or after compiling to javascript (i.e. set breakpoint in java code, launch browser to test and trigger the breakpoint, then inspect java code). Basically GWT fixes a lot of stuff that makes AJAX development suck so much: you work in a advanced IDE instead of a crappy text editor that doesn't have a clue about the semantics of what you type; you debug in one of the best debuggers around; browser compatibility issues are taken care off during compilation; you'll know if there's a type error because Java is statically typed; you can do unit testing; etc. In short, GWT is about bringing lots of good development practices from server side Java to browser client side. There's not that many tools around that do this to the extent that GWT does.
GWT is part of a growing set of web development related technology coming from Google. Other nice stuff is the Guice dependency injection serverside component framework for Java and the Gears offline web application component. Presumably, Google eats their own dogfood so the stuff is demonstrably scalable and quite capable as well. Also interesting to learn for the Java hating crowd on slashdot is that the world's largest internet company is a Java shop.
If you like to fiddle a bit with sound compression and other tools that are used in professional audio mastering, izotope ozone (a commercial product unfortunately) is quite nice to play with. Using a few basic edits can give flat sounding tunes nice warmth and depth. It's basically like the audio equivalent of photoshop and the techniques have very similar intuition.
The problem is not so much the use of such filters but the fact that they are used to optimize recordings for the very mediocre equipment most people use. Subtle bass sounds are simply lost; as are quiet high pitched sounds, because cheap equipment doesn't do anything with this information anyway. To counter this, the trick is to boost the volume of such sounds (relative to the rest) and to shift the spectrum away from very high or very low sounds. Like manipulating photos generally leads to loss of detail and undesired artifacts, manipulating sound results in similar loss of detail and distortion of what remains. Commercial records are edited to the limit of crappy mp3 players and radio. It's the equivalent of boosting a photo's contrast so much that most detail is drowned out to make it look good on a good old matrix printer. The psychological effect is similar as well: we humans appreciate contrast in all sorts of ways and the matrix printer doesn't do grays very well anyway. Unfortunately if you have a high end inkjet printer, such photos don't look much better than on the matrix printer because there is no extra detail anymore.
When used properly however, manipulating sound can improve quality significantly. Many expensive highend amplifiers basically contain lots of dsps to 'improve' the sound and do some restauration work on the distorted signal on the CD (e.g. by interpolating and reinserting detail that was lost in the mastering process). Old fashioned valve based amplifiers are all about sound distortion (in a pleasing way). This is no different than what happens in the studios except that the result would be much better if the studios didn't throw out so much detail. This point can be demonstrated easily by playing back some sixties/seventies recordings which have much less aggressive audio manipulation.
I agree though semantically the difference is that the article tag is going to be standardized, and the div of class article is not. You should of course use the hatom microformat instead and then you would end up using a div with class "hentry". Unlike the article tag, you can use that right now and tools already exist that do smart things with it (e.g. firefox operator extension).
Here lies the real problem. Much of the stuff that html 5 adds is sort of redundant (and in some cases inconsistent with) these microformats; and common use of existing tags. HTML 5 is backwards compatible in the sense that existing browsers will ignore its new tags, not in the sense that stuff works as expected. For example, if you don't want people to see the video on your website then use the new video tag (i.e. don't expect this to show up on youtube any time soon). The old stuff on the other hand is forward compatible and will continue to work. So there is no point at all in using these tags unless you want old browsers to break on your site.
Most content is generated rather than handcrafted so an article tag provides just unneeded syntactic sugar rather than improved semantics. As microformats demonstrate today the use of div and abbr tags combined with use of class names as semantic tags provides plenty of syntax to add all sorts of complicated semantics and ontologies. Compared to that the HTML 5 additions are redundant, rather arbitrary and not really that useful.
So basically, I would encourage the HTML 5 editors to remove all the misguided semantic cruft and focus on consistency and real improvements instead of compatibility breaking syntactic sugar. What is needed is less tags (i.e. deprecate stuff instead of adding stuff). Instead of redoing XHTML, they should endorse and formalize many of the microformats that already cover a wide range of common semantics in a way that really backwards compatible. In so far semantics are missing, new microformats should be suggested rather than compatibility breaking new html constructs.
I know where it came from. You have to admit though, RSS 2.0 has very little to do with RDF anymore, despite the name. I think RSS showed that RDF just wasn't the solution to the problem it tried to address.
The semantic web is being invented now. Only not by Tim Berners Lee et al. The W3C has been side tracked for quite some time by this semantic web thing. Time has been wasted on pointless things such as XHTML, RDF, OWL, etc. Outside the labs, in the real world, a lot more progress is being made. There's millions of geotagged photos, places, wikipedia articles, etc. You can search for hcalendar events on Yahoo, hresumes on linked in, people on facebook and pictures of cats on flickr. Social networks are all about meta information. These applications are now starting to link and integrate each other. That effectively is the birth of the semantic web. It will be a heterogenous patchwork of information applications and services.
If you want a glimpse of what the semantic web will look like, fire up Google Earth. Sure it is proprietary but it is also massively distributed meta information from all over the internet aggregated into one coherent view overlayed on top of the world. Imagine that based on open standards, and you get an idea of where we could be going.
Emerging standards such as microformats, atom, openid may lack the glamour of all encompassing ontologies and the mighty AI of reasoning engines and what not. But, the bottom line is that they are a hell of a lot more practical and pragmatic, solve real problems, and you can use them right now. These emerging standards are not perfect or even complete but people are definitely using them to enrich information on the internet by cross referencing; by tagging; by labeling etc. Defacto standardization outside W3C by killer applications is driving this lower case semantic web. The best thing the W3C could do and currently does not is to endorse, facilitate and promote this work.
Tim Berners Lee of course contributed his bit by inventing the web browser + very naive markup language (aka HTML 1.0) in 1989. I give him credit for his vision then but this article reads like a very confused mix of ideals and vague concepts and does not seem visionary at all. The man tries to explain things in terms of databases, files and links and somehow the wizards at MIT are going to provide the magic pixie dust that turns it into something beautiful. That's nice but the how part remains ever elusive.
Google has basically been approaching lots of people more or less randomly. Including me. Twice so far. I wouldn't actually mind working for a company like Google but I'm not likely to respond positively to random recruiting attemtps.
So why does it not work with people like me? Well very simple. I don't do job interviews. I get invited to discuss specific, custom job descriptions matching my CV & ambition level. We discuss the proposal and then I either accept it or not. I suspect it is like that for most people with a decent level of competence in our business. If you want to hire me, you will need to convince me that you are any good and that it is a substantial improvement over my current job.
If you are going to contact me about a job offer, it had better be specific & well aligned with my interests otherwise I'm not likely to be very enthusiastic about the whole thing. Also I prefer to not deal with HR other than discussing technical details on contracts. If you want to hire me, make sure I talk to the right person right away and don't waste my time with people not capable of telling me anything useful.
Both times I was approached by Google, the person in question hadn't read my CV (on my website); was not aware of my research career (likewise) and did not have a specific job in mind. On the contrary, the first time I talked with a Google HR person, the person projected a months long process with lots of interviews after which I should count myself lucky to be allowed an unspecified job at an unspecified location for an unspecified amount of money. Needless to say I politely declined because if they didn't have anything specific to talk about, our conversation was quite pointless & definitely over.
The downside is simply that openoffice is a lot more limited than MS office in many respects. For many people that is not an issue because all they do is write 2 page memos. At home I have it installed because it is cheap (free) and does a reasonable job of opening the occasional simple word file I need to read. I don't actually do much else with it at home since I do all of my office work at the office.
There, I am a poweruser of MS word and MS powerpoint. Don't get me wrong, these are applications with a lot of flaws but I can get my work done with them despite that. Particularly ms word has a lot of strange bugs, layout problems, etc. But on the other hand it has nice grammar checking and spelling checking features and I know how to work around its more annoying bugs (thanks to years of exposure to them). Word also has nice features for collaborative editing, change reviewing, etc. Overall, it's a very nice word processor that is pretty much unchallenged in terms of features & usability by any other product.
Important for me is the cross reference feature which allows me to refer to sections and references or list items by number. This feature is not properly supported in open office. It has a cross reference insert dialog but it has serious limitations, including the inability to actually list numbered paragraphs and insert a cross reference to one in the document. The number of things you can actually reference is very limited (outline numbered stuff and figure captions) and also the way to configure how to reference is very limited. I've filed the bug before 1.0 and verified that it wasn't fixed for 1.1, 2.0, 2.1 and is currently being considered for 3.0. Basically, the ooo developers agree with me that the current dialog is too limited and also a usability nightmare.
The lack of this feature guarantees I will never use it for any serious writing and is also the single reason I wrote my Ph. D. thesis in framemaker instead of open office (word being just to unstable for such a long, structured document). I can live with the many other limitations but not the lack of cross references. Framemaker is a very lousy wordprocessor of course but great for working with long structured documents like a Ph D thesis with hundreds of cross references to images, tables, (sub) sections, figures, pages etc. Sadly it never really recovered from being bought by Adobe and recent versions did not really improve it much over version 5.x.
I could have used latex of course but I consider the whole concept of compiling & debugging a text just wrong + interoperability with everything else just sucks big time (and no pdf is not interoperable since it is basically a read only format).
My ideal word processor has yet to be invented. It would probably be a mix of the rigid structure provided by framemaker along with its flexibility for formatting and ms word's human friendly approach to actually inputting the text. I can't really think of anything that open office does well in this context except perhaps its drawing tools.
The point would be that it can be done. They're academics.
Having proven that it can be done and having proven that it can be done properly, they effectively prove you and other nay sayers wrong. They are claiming that it works and that it works with acceptable performance (for an emulator). A little out of the box thinking sometimes produces nice results. Why bother with C based emulators if you can do the job in the much more developer friendly Java? As I said, they're academics and probably have better things to do than wrestle with C when they can do the job a lot faster in Java.
As for useful applications of this technology. It requires further out of the box thinking. Of course the whole point of emulation is to run legacy stuff. Some examples: running a dos emulator in CDC java to emulate good old games without having to deploy native code to the phone. Embedding a dos emulator in a J2EE environment to run some legacy x86 server software (e.g. dbase). Both cases are examples where you wouldn't want the emulator to have exploitable memory leaks or drag the OS with it when it crashes. Java based emulators provide that feature, C based emulators don't.
Then, if it can be done for x86, it should be doable for other legacy CPUs as well. Unlike C based emulators, maintenance of this code base is probably a lot more straightforward.
Well sounds nice in theory but I don't see it in practice. I'm aware of numerous very large projects with automated test suites. I'm aware of none (as in 0) very large projects with design by contract practices in place (except maybe for places like NASA which accept rediculously high cost in exchange for better quality).
I don't know what you mean by post hoc writing of contracts. Generally the idea of a contract is that you write the contract first and then the code. Generally the contract writing bit is actually considered to be part of the design process (hence ocl in uml). Maybe you have some alternative interpretation where you write the code first and then do documentation. Not bad, this is actually the practice in the real world of very large software systems. Except there people only document the non trivial bits of code (i.e. the things that need explaining). Dbc requires much more fine grained assertions to be of any use, hence it is much more work then regular after the fact documentation writing (which is expensive already). Anyone claiming otherwise is talking bullshit. Writing detailed contracts for a few hundred kloc is a costly affair whether you do it before, during or after coding. This is the main reason for a near total lack of adoption of dbc in the real world. The reality is that the advertised qualities of dbc have yet to be demonstrated convincingly in large to very large projects. Consequently it is not used for such work, at all (as far as I know), which in itself is a pretty convincing argument against dbc considering it has had a few decades to prove itself in practice.
Design by contract, like most formal method approaches, doesn't scale to interesting levels. If you are working on a 200KLOC project on a tight schedule, the last thing you can afford yourself is increasing time spent per line of code by equipping classes, loops and methods with pre & post conditions. And you would need to do this on a substantial scale to make a significant impact on overall quality. I'm sure most projects could boost quality significantly if you double their budgets but then doing so is unacceptable in most real life situations. Good enough involves balancing a lot of factors and quality is just one of them.
It's great if you can specify that a piece of code is a 100% correct implementation of a given specification but in real life the requirements are sketchy at best & keep changing during development. So, you are likely to end up with the wrong system if you don't adjust your interpretation of them to reality during development. Besides, pre and post conditions need maintenance too if you are doing maintenance on your code, so effectively they increase the cost of what is the single most expensive development activity already: maintenance.
Besides there are other, much more useful tools for improving code quality: unit testing, integration testing, static code checkers, compile time type checking, inspections & reviews are all part of the toolkit of an experienced software engineer and largely remove the need for more formal approaches. Additionally clustering and redundant setups are a far cheaper way of guaranteeing uptime than proving the system to be correct. Risk management is better than trying to avoid risk at all cost.
And finally, the value of 100% correctness is overrated. Most commercial software functions acceptably despite the approximately 10 bugs per kloc. In theory disaster could strike any second, in practice it is a rare event that it does and the consequences are quite manageable usually. Of course things do go spectacularly wrong sometimes and usually people then find out a lot was wrong with the overall development process aside from not applying design by contract. So even then, the added value of design by contract is very questionable. You can't compensate for general incompetence with a couple of pre and post conditions.
Not having data local on a laptop that can get stolen is a lot more secure than having them on a huge cluster of servers with Google guaranteeing scalability, quality of services, more or less continuous back ups etc.
Outsourcing file and mail services is nothing new, IBM has been doing it for years and for most companies it is a lot more secure than putting their idiot sysadmin in charge of some Dell server running exchange. Adding office stuff is a small step if you can live with the reduced featureset that Google offers. Though some of their stuff is not that bad. For instance, I prefer the Google calendar to outlook which I have to use at work. Same for gmail (faster, better search).
Re:a scripting language that targets the java vm !
on
Groovy in Action
·
· Score: 1
1) Basically any server application needs to run all the time. 2) Starting the vm on a modern machine takes about 0.5 seconds. 3) Loading a few MB worth of libraries of course takes time; in any language. J2ee servers are indeed huge. But then they also include a lot of functionality and actually most of the time it spends booting it is actually executing functionality rather than loading libraries. 4) Groovy is compiled to bytecode. That means it is being JIT compiled. Which makes perfect sense in a server environment. Since the JVM has mechanisms for dynamically loading and unloading classes, that does not conflict with the dynamic nature of a language like groovy. 5) Scripting is about more than the unix shell, although ant+groovy is a very useful addition to that toolset. 6) Serverside groovy doesn't work like cgi scripts (well it could but only a retard would use it like that). It merely builds on one of the early innovations over cgi to not kill the process in between requests. This has been commonly used in the servlet APIs since about 1998 and most apache modules now do something similar (e.g. php). Building on the J2ee architecture gives a few scalability benefits to groovy that most other scripting just lack. 7) If you are a webmaster, you should know all of the above.
And yes, you were way off base. Basically all the assumptions you made are plain wrong.
The report starts with a four page executive summary, which is worth a read. Seems to include a few nice conclusions. I'd have to read the full report to assess credibility of course but I guess for most people here the executive summary should provide some nice new ammunition.
This happened last year. There've been several follow ups to the original blogpost on how the situation was resolved. There's even a guy from google who showed up in the forum and offered his helped to fix things. By now the damage has been undone of course but for some time Google stopped returning any javalobby results.
Btw. it's javalobby.org, they're not for profit and sort of pay the bills with the advertisements. Just like slashdot. I've been a member of their site since 1998 and they're good guys.
The problem is that most system administrators consider a firewall as a means to limit user freedom. This is a way for users to bypass such restrictions (given a poorly configured firewall). From that point of view this might be bad if it weren't for the fact that they have plenty of tools left to prevent this kind of thing. In a corporate network this should be a non issue.
From a security point of view it is not so bad, however. The approach requires software inside the firewall to initiate a connection. Firewalls can be configured to prevent this if needed but in many cases the firewall is just there to prevent uninvited guests rather than to limit end user freedom (and initiating a request from the inside implies invited guest). The only difference is that now you can initiate connections to a computer that is also firewalled.
HDs are comparatively slow and flash drives are approaching the big enough state where they could replace them in e.g. laptops and workstations. Currently vista already works better with a hybrid approach (using flash for swap space). Once the flash drives become big enough (e.g. the just announced 32 GB flash thingy from Sony), they become a drop in replacement for slow, hot, noisy and energy wasting harddrives. Also there's no reason why these things could not be operated in a raid like configuration. What about a RAID5 with 20, 10GB flash drives. One breaks down, you just plug in a new one. Mark my words, harddrives will be used only as secondary storage and in file servers in a few years.
Slashdot Mirror
Something like this http://www.naked.la/, might provide some inspiration for them. Basically this company is launching a beta tonight of a next generation photo editing toolsuite that includes non destructive and resolution & bitdepth independent editing.
Apple only unfortunately.
It used to be that whenever somebody posted something about a device to slashdot people would jokingly ask if it ran linux. Well, the N770 and N800 were a huge hit with that type of people and the N810 is a very nice upgrade for them. It basically builds on what made those devices so popular in the first place. It's the ultimate hackable linux mobile device. It ships with a big enough touch screen, slidable keyboard, GPS and plenty of juice to run a very wide and growing variety of linux software.
I work at Nokia and although I cannot speak on behalf of my employer (i.e. disclaimer applies) I can say that n770 and n800 have been a huge success in the market. These devices have literally been flying from the shelves since we started shipping them. The thing went absolutely viral despite us not spending that much effort on marketing them initially. The people buying these devices are a mixed bag of people but a substantial amount of them appear to be linux enthusiasts who get from Nokia something that they cannot really get from anyone else currently: a hackable, mobile linux based device with a well supported and really broad development community. Sure there's lots of other mobile linux devices on the market but they pretty much all suck because they've been locked down or because they are unstable or because they have very mediocre hardware. This sounds like it is a handful of people but actually world wide we are talking about a quite large group of people.
For example I interact a lot with researchers in the academic world and for them this series of internet tablets is hugely popular due to fact that it so damn easy for them to implement their research prototypes on them (e.g. ubiquitous computing related research). They're ordering them by the dozens. Of course there are also lots of people who are just pretty happy with the included features and don't actually bother to install extra software. And of course, with the right applications installed, it's also a pretty good enterprise device. Installing those is easy, just use apt-get install or the nice packagemanager or just click on the package in the browser.
As for quality and battery life. I've been using this N800 for several months now. If you use it non stop, it will last you only 4 hours or so. On the other hand unless you use it to watch a movie, you are more likely to just occasionally use it for a few minutes at the time. In that case it can actually last a few days easily. For example, I routinely leave the device on my desk with an open shh connection to it and come back in the morning to find that it is still running fine and has plenty of juice left to make it through another day of testing my software on it. Bottom line is that power management works pretty well on the device. Quality of the software is also pretty good. Major improvements were made to the WLAN in subsequent firmware releases and it is now a lot more stable and power efficient than with earlier releases. Developing on it means I install lots of experimental stuff on the device. Despite this, I can't actually recall the thing resetting or kernel panicking.
To get back to why this niche is important. I can't say why but obviously a lot of companies besides Nokia have become interested in developing n800 like tablets. For example intel seems to bet on this with their maemo derived linux platform. Also the openmoko people are sharing a lot of code with maemo. Apple seems interested in pushing this formfactor a bit further and MS has been pushing pda like phones for years now. There's plenty of tablet like products headed for the market and N810 is some of the better ones currently available.
Windows build is just as large as the apple build. So where did they hide the jre? They might be doing some work arounds for some native issues. The AWT issue sounds like one and I'm aware of Apple having provided eclipse with workarounds for issues in their code like the apple.awt.usingSWT system property on Mac.
Maybe eclipse also puts some replacements for core classes on the boot classpath.
Good to know somebody is working on openjdk on Mac.
1) as a developer I like to stay up to speed with latest developments in my field. Even if I deploy on 1.5, I'll still develop on 1.6. Actually I'm deploying on CDC Java currently. I know many other developers do the same. Of course you need to test on 1.4 as well. Also, deploying your 1.4 code on a 1.6 VM works just fine and buys you some nice performance & manageability advantages (i.e. technically you'd have to be really conservative to not want that). For some server environments, people use what is supported by the vendor rather than what works best, That's one of the major reasons you still find old 1.4 vms (or worse) running in production environments. 1.3 you might also find even though Sun has long stopped supporting it with security patches and is planning to stop support for 1.4 as well.
2) I care because Apple as a technology provider is years behind Sun and I have no other choice than Apple on a Mac. Apple as a deployment option is ok but as a development option it is simply to limiting for me.
3) like all the native stuff that for example integrates swing into quartz; the virtual machine implementation; etc. The problem is that those native bits have compatibility issues with the native SWT bits in eclipse AND that Apple has been very reluctant to do anything about it (see 2).
4) must have been an old version, I think the compatibility issues appeared in the 3.x cycle.
So yes you are right that if 1-4 are a non issue for you now and during the time you will own the mac, you can develop on it. I hope you agree that some level of awareness of these issues would be nice during purchase decisions. In any case for me that is a reason to stay away from Macs. By the time Apple finally ships 1.6, I will be testing on open source 1.7 builds already.
Sorry but that's nonsense as well. Eclipse uses its own compiler (100% Java) for compiling Java which works just fine on pretty much any java virtual machine, including Apple's and a lot of experimental ones (which is a huge advantage of the eclipse compiler). Eclipse does not bundle a custom java virtual machine on any platform, including mac.
Openjdk.net does not provide mac os X builds so don't hope too much. As far as I know there is no work going on for an open source replacement for the closed source apple java implementation.
I'm a Java programmer and I use eclipse. The reason I can't use a Mac is that
1) it still does not support java 1.6 because Apple chooses to bundle new Java versions with new OS versions instead of distributing them separately like the rest of the world does. In practice that means there's up to 1 year or longer (as in this case) before new Java versions find their way onto the Mac.
2) sun does not directly support Mac OS X but leaves the job of porting to Apple, unlike linux, windows and solaris which it does support.
3) If you want to use Sun's OSS Java version on the Mac, you are on your own and will just have to come up with the native mac specific stuff yourself.
4) eclipse has a long history of compatibility issues with Apple's Mac OS X UI Java bindings in their native code for SWT (i.e. this is a C portability issue, not a Java portability issue). It sort of works now but is not quite ideal.
If all of the above is acceptable to you, by all means use a mac for Java development. For me, all of these are unacceptable because I require early access to new Java stuff.
Sun being in charge is not necessarily the problem; the problem is that they lack the competence and vision to bring the necessary changes to OOo and are making it hard to bring in external expertise to fix it. Lets face it, they're a hardware company that also does server software. They sell products to enterprises, not to people. They've never had to deal with end users and they are not very good at it.
The simple reality is that Sun historically has done a less than great job designing and implementing user interfaces for end users. It's true for netbeans; solaris; Java and indeed open office that each of these products has a very long history of quirky, non standard user interfaces that pale to competing products. In all these products progress has been made. Basically solaris now sports a nice Gnome desktop (but they took their time killing their old UI), netbeans is undergowing the zillionth lets "fix the UI" effort, Java did great on the serverside but so far failed to get people enthousiastic on the desktop side (JavaFX being the latest misguided/doomed effort).
The Open office UI looks out of place on any platform. Ugly icons; weird fonts; clumsy stuff like the cross references dialog or the poor excuse for a bibliography manager. Yes you can sort of do most office related stuff in it and for most people that is enough. Sun has been fighting the symptoms for years and they seem to be pretty proud of their work. The truth however is that the overall Sun UI experience is mediocre or adequate at best across their product line.
What open office needs is somebody like Blake Ross to kick out the old UI and do a proper one. Blake and friends rescued the quirky mozilla from the fate that OOo is now facing: being a second choice cheap product that people use for cost rather than quality.
I have about ten years of experience with installing linux distributions (to see what the latest hype/fuss is about) and usually discarding them after the novelty wears off. I'm still a windows guy but my dependencies to win32 specific stuff are fairly limited now. The reason I stick with it is the usual mix of games and a handful of stuff I'd prefer not to be separated from (none of it from MS).
/etc/network/interfaces and hoping the network manager picks up the changes. I had loads of other problems too. Part of my network trouble caused the installer to hang indefinitely "scanning the mirrors". I had to switch to a console to kill some processes to make it progress. Finally Gparted gave me a pretty good scare at some point by throwing really obscure errors at me for no good reason (made me think my windows partition was gone when it wasn't). In general using the back button in the installer seems a bad idea. Gparted gets awfully confused by that.
Anyway, I think the review is spot on. Ubuntu has many rough edges and it fixes them by removing the functionality needed to work around them. Basically out of the box, all my hardware was misconfigured (which is excusable for a OS aimed at nerds like me). To fix it I found myself making round trips to the ubuntu forums to figure out which packages to install and what tools to use to finish the job the installer should have done. Specifically, like on so many computers Ubuntu botched the monitor detection (upcoming release should fix that). No big deal but the tool to help you fix it is not installed (probably for usability reasons). Same for alsa config which messed up choosing from three sound cards by redirecting all sound to my usb headset (nice to know it works though) instead of my audigy card which is plugged into a motherboard with yet another sound related chipset. I needed to install a tool to set the default card. Finally, I found the network manager to be a little too obnoxious. I had some issues with a buggy driver for my SIS190 network card. The network manager only got in the way when trying to 'configure' the network, which boils down to editing
Then there is the stuff included in the default install. Rhythmbox crashed a few times on me. That could be one of those pesky mp3 plugins it installed for me. The 3d effects were indeed useless (wise choice to not enable that by default). My first ubuntu update (before installing any software) failed due to a bug in the font server package. Luckily the obscure error produced the right hit in Google along with a bunch of touch commands to give some files the right timestamp. The bug was months old.
I eventually managed to fix everything that ubuntu did wrong and after fixing it is a pretty nice system though not significantly nicer than other distributions I have tried in recent years. So I have to agree here that it is just not for end users. Claiming it is, is just not realistic. Any of the problems I encountered would prove unfixable for novice users. Ubuntu pretends usability by not including notoriously hard to use but essential tools. Unfortunately that means you are on your own when you venture outside the rather narrow set of cases where it manages to configure things automatically. I'm sure there are cases where ubuntu gets everything right and I'm sure it is getting better with each release but from what I've seen it just isn't there yet.
I can understand people not reading every link on a slashdot article they comment on. But if you post the bloody link, is it too much asked to actually RTFA?! It's an article about a column. The actual column is quite interesting.
To add some content, this is about optimal storage for SQL databases in a data warehouse context where there are some interesting products that use something more optimal than the one size fits all solutions currently available from the big RDBMS vendors. The API on top is the same (i.e. SQL and other familiar dataware house APIs), which makes it quite easy to integrate.
Regarding the obsolescence question, one size fits all will be good enough for most for some time to come. Increasingly people are more than happy with lightweight options that are even less efficient on which they slap persistence layers that reduce performance even more just because it allows them to autogenerate all the code that deals with stuffing boring data in some storage. Not having to deal with that makes it irrelevant how the database works and allows you to focus on how you work with the data rather than worrying about tables, rows and ACID properties. Autogenerating code that interacts with the database allows you to do all sorts of interesting things in the generated code and the layers underneath. For example, the hibernate (a popular persistence layer for Java) people have been integrating Apache Lucene, a popular search index product, so that you can index and search your data objects using lucene search queries rather than sql. It's a quite neat solution that adds real value (e.g. fully text searchable product catalogs are dead easy with this).
Column based storage is just an optimization and not really that critical to the applications on top. If you need it, there are some specialized products currently. The author of the column is probably right about such solutions finding their way into mainstream products really soon. At the application level, you'll still be talking good old SQL to the damn thing though.
GWT is a development kit for developing AJAX applications, such as for example GMail. The concept consists of doing all the programming in Java (similar to how you would develop a Java desktop application) and cross compiling the client components to javascript + html. The advantage of this is that you don't have to think about html, javascript, browser-server communication and many other difficult browser issues that most other web developers waste most of their time on (instead of implementing functionality). GWT makes things like interacting with the browser history, back button and other difficult to do stuff dead easy. Basically the toolkit encapsulates all the javascript voodoo that you normally need to do to do this properly & cross browser. Just define all logic as Java code GWT generates the rest. Of course you can also go for a partial approach where you do part of the application using ordinary javascript and html and only do parts of the app in GWT. Basically this allows you to use as much or as little of GWT as you need.
The IDE part is integrated into eclipse and offers all the advanced development features that Java programmers are used to like incremental compilation, refactoring, auto-completion etc. To the developer, GWT looks like just another Java library that builds on all the idioms and patterns they know already. Of course you can debug your application as well either before or after compiling to javascript (i.e. set breakpoint in java code, launch browser to test and trigger the breakpoint, then inspect java code). Basically GWT fixes a lot of stuff that makes AJAX development suck so much: you work in a advanced IDE instead of a crappy text editor that doesn't have a clue about the semantics of what you type; you debug in one of the best debuggers around; browser compatibility issues are taken care off during compilation; you'll know if there's a type error because Java is statically typed; you can do unit testing; etc. In short, GWT is about bringing lots of good development practices from server side Java to browser client side. There's not that many tools around that do this to the extent that GWT does.
GWT is part of a growing set of web development related technology coming from Google. Other nice stuff is the Guice dependency injection serverside component framework for Java and the Gears offline web application component. Presumably, Google eats their own dogfood so the stuff is demonstrably scalable and quite capable as well. Also interesting to learn for the Java hating crowd on slashdot is that the world's largest internet company is a Java shop.
If you like to fiddle a bit with sound compression and other tools that are used in professional audio mastering, izotope ozone (a commercial product unfortunately) is quite nice to play with. Using a few basic edits can give flat sounding tunes nice warmth and depth. It's basically like the audio equivalent of photoshop and the techniques have very similar intuition.
The problem is not so much the use of such filters but the fact that they are used to optimize recordings for the very mediocre equipment most people use. Subtle bass sounds are simply lost; as are quiet high pitched sounds, because cheap equipment doesn't do anything with this information anyway. To counter this, the trick is to boost the volume of such sounds (relative to the rest) and to shift the spectrum away from very high or very low sounds. Like manipulating photos generally leads to loss of detail and undesired artifacts, manipulating sound results in similar loss of detail and distortion of what remains. Commercial records are edited to the limit of crappy mp3 players and radio. It's the equivalent of boosting a photo's contrast so much that most detail is drowned out to make it look good on a good old matrix printer. The psychological effect is similar as well: we humans appreciate contrast in all sorts of ways and the matrix printer doesn't do grays very well anyway. Unfortunately if you have a high end inkjet printer, such photos don't look much better than on the matrix printer because there is no extra detail anymore.
When used properly however, manipulating sound can improve quality significantly. Many expensive highend amplifiers basically contain lots of dsps to 'improve' the sound and do some restauration work on the distorted signal on the CD (e.g. by interpolating and reinserting detail that was lost in the mastering process). Old fashioned valve based amplifiers are all about sound distortion (in a pleasing way). This is no different than what happens in the studios except that the result would be much better if the studios didn't throw out so much detail. This point can be demonstrated easily by playing back some sixties/seventies recordings which have much less aggressive audio manipulation.
I agree though semantically the difference is that the article tag is going to be standardized, and the div of class article is not. You should of course use the hatom microformat instead and then you would end up using a div with class "hentry". Unlike the article tag, you can use that right now and tools already exist that do smart things with it (e.g. firefox operator extension).
Here lies the real problem. Much of the stuff that html 5 adds is sort of redundant (and in some cases inconsistent with) these microformats; and common use of existing tags. HTML 5 is backwards compatible in the sense that existing browsers will ignore its new tags, not in the sense that stuff works as expected. For example, if you don't want people to see the video on your website then use the new video tag (i.e. don't expect this to show up on youtube any time soon). The old stuff on the other hand is forward compatible and will continue to work. So there is no point at all in using these tags unless you want old browsers to break on your site.
Most content is generated rather than handcrafted so an article tag provides just unneeded syntactic sugar rather than improved semantics. As microformats demonstrate today the use of div and abbr tags combined with use of class names as semantic tags provides plenty of syntax to add all sorts of complicated semantics and ontologies. Compared to that the HTML 5 additions are redundant, rather arbitrary and not really that useful.
So basically, I would encourage the HTML 5 editors to remove all the misguided semantic cruft and focus on consistency and real improvements instead of compatibility breaking syntactic sugar. What is needed is less tags (i.e. deprecate stuff instead of adding stuff). Instead of redoing XHTML, they should endorse and formalize many of the microformats that already cover a wide range of common semantics in a way that really backwards compatible. In so far semantics are missing, new microformats should be suggested rather than compatibility breaking new html constructs.
I know where it came from. You have to admit though, RSS 2.0 has very little to do with RDF anymore, despite the name. I think RSS showed that RDF just wasn't the solution to the problem it tried to address.
The semantic web is being invented now. Only not by Tim Berners Lee et al. The W3C has been side tracked for quite some time by this semantic web thing. Time has been wasted on pointless things such as XHTML, RDF, OWL, etc. Outside the labs, in the real world, a lot more progress is being made. There's millions of geotagged photos, places, wikipedia articles, etc. You can search for hcalendar events on Yahoo, hresumes on linked in, people on facebook and pictures of cats on flickr. Social networks are all about meta information. These applications are now starting to link and integrate each other. That effectively is the birth of the semantic web. It will be a heterogenous patchwork of information applications and services.
If you want a glimpse of what the semantic web will look like, fire up Google Earth. Sure it is proprietary but it is also massively distributed meta information from all over the internet aggregated into one coherent view overlayed on top of the world. Imagine that based on open standards, and you get an idea of where we could be going.
Emerging standards such as microformats, atom, openid may lack the glamour of all encompassing ontologies and the mighty AI of reasoning engines and what not. But, the bottom line is that they are a hell of a lot more practical and pragmatic, solve real problems, and you can use them right now. These emerging standards are not perfect or even complete but people are definitely using them to enrich information on the internet by cross referencing; by tagging; by labeling etc. Defacto standardization outside W3C by killer applications is driving this lower case semantic web. The best thing the W3C could do and currently does not is to endorse, facilitate and promote this work.
Tim Berners Lee of course contributed his bit by inventing the web browser + very naive markup language (aka HTML 1.0) in 1989. I give him credit for his vision then but this article reads like a very confused mix of ideals and vague concepts and does not seem visionary at all. The man tries to explain things in terms of databases, files and links and somehow the wizards at MIT are going to provide the magic pixie dust that turns it into something beautiful. That's nice but the how part remains ever elusive.
Google has basically been approaching lots of people more or less randomly. Including me. Twice so far. I wouldn't actually mind working for a company like Google but I'm not likely to respond positively to random recruiting attemtps.
So why does it not work with people like me? Well very simple. I don't do job interviews. I get invited to discuss specific, custom job descriptions matching my CV & ambition level. We discuss the proposal and then I either accept it or not. I suspect it is like that for most people with a decent level of competence in our business. If you want to hire me, you will need to convince me that you are any good and that it is a substantial improvement over my current job.
If you are going to contact me about a job offer, it had better be specific & well aligned with my interests otherwise I'm not likely to be very enthusiastic about the whole thing. Also I prefer to not deal with HR other than discussing technical details on contracts. If you want to hire me, make sure I talk to the right person right away and don't waste my time with people not capable of telling me anything useful.
Both times I was approached by Google, the person in question hadn't read my CV (on my website); was not aware of my research career (likewise) and did not have a specific job in mind. On the contrary, the first time I talked with a Google HR person, the person projected a months long process with lots of interviews after which I should count myself lucky to be allowed an unspecified job at an unspecified location for an unspecified amount of money. Needless to say I politely declined because if they didn't have anything specific to talk about, our conversation was quite pointless & definitely over.
The downside is simply that openoffice is a lot more limited than MS office in many respects. For many people that is not an issue because all they do is write 2 page memos. At home I have it installed because it is cheap (free) and does a reasonable job of opening the occasional simple word file I need to read. I don't actually do much else with it at home since I do all of my office work at the office.
There, I am a poweruser of MS word and MS powerpoint. Don't get me wrong, these are applications with a lot of flaws but I can get my work done with them despite that. Particularly ms word has a lot of strange bugs, layout problems, etc. But on the other hand it has nice grammar checking and spelling checking features and I know how to work around its more annoying bugs (thanks to years of exposure to them). Word also has nice features for collaborative editing, change reviewing, etc. Overall, it's a very nice word processor that is pretty much unchallenged in terms of features & usability by any other product.
Important for me is the cross reference feature which allows me to refer to sections and references or list items by number. This feature is not properly supported in open office. It has a cross reference insert dialog but it has serious limitations, including the inability to actually list numbered paragraphs and insert a cross reference to one in the document. The number of things you can actually reference is very limited (outline numbered stuff and figure captions) and also the way to configure how to reference is very limited. I've filed the bug before 1.0 and verified that it wasn't fixed for 1.1, 2.0, 2.1 and is currently being considered for 3.0. Basically, the ooo developers agree with me that the current dialog is too limited and also a usability nightmare.
The lack of this feature guarantees I will never use it for any serious writing and is also the single reason I wrote my Ph. D. thesis in framemaker instead of open office (word being just to unstable for such a long, structured document). I can live with the many other limitations but not the lack of cross references. Framemaker is a very lousy wordprocessor of course but great for working with long structured documents like a Ph D thesis with hundreds of cross references to images, tables, (sub) sections, figures, pages etc. Sadly it never really recovered from being bought by Adobe and recent versions did not really improve it much over version 5.x.
I could have used latex of course but I consider the whole concept of compiling & debugging a text just wrong + interoperability with everything else just sucks big time (and no pdf is not interoperable since it is basically a read only format).
My ideal word processor has yet to be invented. It would probably be a mix of the rigid structure provided by framemaker along with its flexibility for formatting and ms word's human friendly approach to actually inputting the text. I can't really think of anything that open office does well in this context except perhaps its drawing tools.
The point would be that it can be done. They're academics.
Having proven that it can be done and having proven that it can be done properly, they effectively prove you and other nay sayers wrong. They are claiming that it works and that it works with acceptable performance (for an emulator). A little out of the box thinking sometimes produces nice results. Why bother with C based emulators if you can do the job in the much more developer friendly Java? As I said, they're academics and probably have better things to do than wrestle with C when they can do the job a lot faster in Java.
As for useful applications of this technology. It requires further out of the box thinking. Of course the whole point of emulation is to run legacy stuff. Some examples: running a dos emulator in CDC java to emulate good old games without having to deploy native code to the phone. Embedding a dos emulator in a J2EE environment to run some legacy x86 server software (e.g. dbase). Both cases are examples where you wouldn't want the emulator to have exploitable memory leaks or drag the OS with it when it crashes. Java based emulators provide that feature, C based emulators don't.
Then, if it can be done for x86, it should be doable for other legacy CPUs as well. Unlike C based emulators, maintenance of this code base is probably a lot more straightforward.
Well sounds nice in theory but I don't see it in practice. I'm aware of numerous very large projects with automated test suites. I'm aware of none (as in 0) very large projects with design by contract practices in place (except maybe for places like NASA which accept rediculously high cost in exchange for better quality).
I don't know what you mean by post hoc writing of contracts. Generally the idea of a contract is that you write the contract first and then the code. Generally the contract writing bit is actually considered to be part of the design process (hence ocl in uml). Maybe you have some alternative interpretation where you write the code first and then do documentation. Not bad, this is actually the practice in the real world of very large software systems. Except there people only document the non trivial bits of code (i.e. the things that need explaining). Dbc requires much more fine grained assertions to be of any use, hence it is much more work then regular after the fact documentation writing (which is expensive already). Anyone claiming otherwise is talking bullshit. Writing detailed contracts for a few hundred kloc is a costly affair whether you do it before, during or after coding. This is the main reason for a near total lack of adoption of dbc in the real world. The reality is that the advertised qualities of dbc have yet to be demonstrated convincingly in large to very large projects. Consequently it is not used for such work, at all (as far as I know), which in itself is a pretty convincing argument against dbc considering it has had a few decades to prove itself in practice.
Design by contract, like most formal method approaches, doesn't scale to interesting levels. If you are working on a 200KLOC project on a tight schedule, the last thing you can afford yourself is increasing time spent per line of code by equipping classes, loops and methods with pre & post conditions. And you would need to do this on a substantial scale to make a significant impact on overall quality. I'm sure most projects could boost quality significantly if you double their budgets but then doing so is unacceptable in most real life situations. Good enough involves balancing a lot of factors and quality is just one of them.
It's great if you can specify that a piece of code is a 100% correct implementation of a given specification but in real life the requirements are sketchy at best & keep changing during development. So, you are likely to end up with the wrong system if you don't adjust your interpretation of them to reality during development. Besides, pre and post conditions need maintenance too if you are doing maintenance on your code, so effectively they increase the cost of what is the single most expensive development activity already: maintenance.
Besides there are other, much more useful tools for improving code quality: unit testing, integration testing, static code checkers, compile time type checking, inspections & reviews are all part of the toolkit of an experienced software engineer and largely remove the need for more formal approaches. Additionally clustering and redundant setups are a far cheaper way of guaranteeing uptime than proving the system to be correct. Risk management is better than trying to avoid risk at all cost.
And finally, the value of 100% correctness is overrated. Most commercial software functions acceptably despite the approximately 10 bugs per kloc. In theory disaster could strike any second, in practice it is a rare event that it does and the consequences are quite manageable usually. Of course things do go spectacularly wrong sometimes and usually people then find out a lot was wrong with the overall development process aside from not applying design by contract. So even then, the added value of design by contract is very questionable. You can't compensate for general incompetence with a couple of pre and post conditions.
Not having data local on a laptop that can get stolen is a lot more secure than having them on a huge cluster of servers with Google guaranteeing scalability, quality of services, more or less continuous back ups etc.
Outsourcing file and mail services is nothing new, IBM has been doing it for years and for most companies it is a lot more secure than putting their idiot sysadmin in charge of some Dell server running exchange. Adding office stuff is a small step if you can live with the reduced featureset that Google offers. Though some of their stuff is not that bad. For instance, I prefer the Google calendar to outlook which I have to use at work. Same for gmail (faster, better search).
1) Basically any server application needs to run all the time.
2) Starting the vm on a modern machine takes about 0.5 seconds.
3) Loading a few MB worth of libraries of course takes time; in any language. J2ee servers are indeed huge. But then they also include a lot of functionality and actually most of the time it spends booting it is actually executing functionality rather than loading libraries.
4) Groovy is compiled to bytecode. That means it is being JIT compiled. Which makes perfect sense in a server environment. Since the JVM has mechanisms for dynamically loading and unloading classes, that does not conflict with the dynamic nature of a language like groovy.
5) Scripting is about more than the unix shell, although ant+groovy is a very useful addition to that toolset.
6) Serverside groovy doesn't work like cgi scripts (well it could but only a retard would use it like that). It merely builds on one of the early innovations over cgi to not kill the process in between requests. This has been commonly used in the servlet APIs since about 1998 and most apache modules now do something similar (e.g. php). Building on the J2ee architecture gives a few scalability benefits to groovy that most other scripting just lack.
7) If you are a webmaster, you should know all of the above.
And yes, you were way off base. Basically all the assumptions you made are plain wrong.
The report starts with a four page executive summary, which is worth a read. Seems to include a few nice conclusions. I'd have to read the full report to assess credibility of course but I guess for most people here the executive summary should provide some nice new ammunition.
This happened last year. There've been several follow ups to the original blogpost on how the situation was resolved. There's even a guy from google who showed up in the forum and offered his helped to fix things. By now the damage has been undone of course but for some time Google stopped returning any javalobby results.
Btw. it's javalobby.org, they're not for profit and sort of pay the bills with the advertisements. Just like slashdot. I've been a member of their site since 1998 and they're good guys.
The problem is that most system administrators consider a firewall as a means to limit user freedom. This is a way for users to bypass such restrictions (given a poorly configured firewall). From that point of view this might be bad if it weren't for the fact that they have plenty of tools left to prevent this kind of thing. In a corporate network this should be a non issue.
From a security point of view it is not so bad, however. The approach requires software inside the firewall to initiate a connection. Firewalls can be configured to prevent this if needed but in many cases the firewall is just there to prevent uninvited guests rather than to limit end user freedom (and initiating a request from the inside implies invited guest). The only difference is that now you can initiate connections to a computer that is also firewalled.
HDs are comparatively slow and flash drives are approaching the big enough state where they could replace them in e.g. laptops and workstations. Currently vista already works better with a hybrid approach (using flash for swap space). Once the flash drives become big enough (e.g. the just announced 32 GB flash thingy from Sony), they become a drop in replacement for slow, hot, noisy and energy wasting harddrives. Also there's no reason why these things could not be operated in a raid like configuration. What about a RAID5 with 20, 10GB flash drives. One breaks down, you just plug in a new one. Mark my words, harddrives will be used only as secondary storage and in file servers in a few years.