No language is without flaws. In C, the golden boy among die-hard geeks, you spend as much time managing memory and pointers as you do creating application logic. C++ saves many of those problems while introducing new pseudo-OO constructs that have peculiar and arcane rules governing their use. C# opts to provide far too many keywords for nearly identical behaviors and then renames half of them to look "new". Perl is terribly powerful, but can become obfuscated and impossible to maintain if used most efficiently. VB glosses over so many basic programming principles that its users waste time and CPU cycles re-reinventing the wheel. I can't say I know what's wrong with many others because I haven't used them, but no language is perfect.
That said, Java has terrific benefits and some deadly flaws. JSPs, for one, are a mess. Embedding code for even such simple tasks as displaying dynamic fields is error-prone and difficult to maintain. Add to that the fact that so many JSP developers leave reams of business code in the JSPs themselves, and the hackish nature of JSP comes to light. This is not, however, a simple Java problem, and it plagues any similar templating languages. I have seen some ASP pages that were phenomenally large. Bad practice is bad practice, irregardless of where it occurs.
Java also suffers, as many know, from serious memory issues. In the rush to provide a single language platform for applications across all aspects of software engineering, Java tries to do too much in too many places. Java can be embedded inside phones for small Internet clients and video games, or loaded onto the largest servers for massive Java-based enterprise integration applications. It does both of those things exceedingly well, providing powerful abstractions at both micro and macro levels. The grey area in the middle is where most people stumble. Drawing the line between "enterprise" and "standard" code libraries is very difficult, and many "enterprise" features remain in the "standard" version of Java, adding to the bloat. What's worse, only within the last couple years has the question of memory consumption begun to be addressed in earnest by Sun engineers. There are many lights ahead, however, be it the improved base memory handling in Java 1.5, or the eventual integration of Apple's VM-sharing innovations into the Sun Java proper.
Java being staticly type has other problematic side-effects; namely, as data and systems outside an application change or as the application as a whole needs to grow and adapt to new requirements, single small changes in a few classes can explode into massive alterations throughout the system. Again, much of this can be mitigated with rigid adherence to preferred OO practices. If those practices are not enough, there are a number of freely-available APIs and libraries to allow for more dynamicity and looser coupling between tiers, almost certainly easing these upward transitions.
At the end of the day, any software development group wants the tool that gets the job done. No project I've ever been associated with chose Java because of market hype or buzzword psychosis. They chose Java because it presented the most complete set of enterprise service abstractions in a single platform, without needing vast amounts of glue code to aggregate them into a single, homogeneous enterprise application. I have also never been on a Java project that failed, although many stumbled along the way. Java is not market-successful simply because it is hyped, or because it is trendy, or because I say so. It is successful because it provides developers more tools in a single toolbox than other comparable languages.
Interfaces are only half of the story. Interfaces without implementations are absolutely worthless. Microsoft owns the "standard" implementation of all the interfaces they've published. No matter how well documented, no matter how clear the contract, all implementations will have peripheral, unspecified behavior. In Microsoft's case, perhaps it will interface with the OS primitives better because of information only Microsoft knows. Perhaps it will interface better with Microsoft products because of intimate knowledge of unpublished shortcuts only Microsoft knows. There's an endless number of ways that Microsoft can change their implementation and result in interoperability problems with other non-Microsoft implementations.
You also seem to ignore many of the other points...large portions of.NET are still Microsoft proprietary and will have to be cloned. Microsoft doesn't have to make any guarantees about clones working the same way their original implementations do. Not only that, but the fact that these are interfaces says nothing for the fact that Microsoft can add features to their.NET without providing any information or support to alternative implementations. What will Mono do if Microsoft doesn't standardize the next version of C#, or just adds additional features across the board without publishing information or providing support to implement them? Fork.NET?
You forget the key principle behind which Microsoft has managed to succeed: Embrace and extend. They've done it before to other open standards that they had no control over. You're trying to tell me they won't do the same thing when they DO control the items that are standardized?
Selectively closing revised portions of.NET over time, or feeding information on them just a bit too slowly to alternative implementations won't hurt Windows-based.NET developers one bit, but it certainly will cause non-Windows-based.NET developers to consider moving. History has shown this is EXACTLY how Microsoft works.
Mono is a great piece of software. That said, the only benefits I can see to having it exist are to Microsoft and Ximian. I don't understand the naivete that makes people think "Microsoft won't screw us this time." As Miguel has admitted in the Mono FAQ referenced in another reply, large portions of.NET are still proprietary Microsoft creations. Sure, you can port them, but then Microsoft can just change them or add features, and you're always a step behind. If they're feeling really pushy, they can push for legal action.
It doesn't really stop there. The standardized portions of.NET are such a small part of the whole platform as to be laughable. Sure, the language is standard. Whoopty-freaking-do. As any developer knows, just having a standardized language does not a development platform make. And in this case, a FOSS-based.NET is far, far from being a safe, platform-independent enterprise application environment.
It comes down to a simple truth: Microsoft does what's best for MICROSOFT. Everything they do is focused in increasing revenues and expanding market share. Why is.NET such a big new item these days? Because Microsoft's bully tactics haven't given them a decisive share of Internet development traffic. Even the name.NET is created to ensnare CTOs into thinking this is the way to go. At the end of the day, Microsoft is not a company that gives away technology and opens the door to alternative operating systems and development platforms. If they open the door at all, it's only to lock you in to one of their proprietary technologies.
Open source will not save your soul here. Unless you have some magical codebase that's going to automatically include the new features Microsoft is certain to release in their platform-specific implementation, the FOSS version will always, ALWAYS be a step behind...and that step will probably be really big. So what if the source is open? It's going to be feature-incomplete, last month's/year's technology, and possibly legally questionable. Sounds like a winning combination for your core mission-critical apps. Sounds like a certain path to the original Creator of said platform...a path away from FOSS.
Please, do not be fooled. This recipe has been repeated again and again.
1. Release semi-standardized software, api, or development platform while holding onto patents for large, key portions 2. Wait until a large community builds around those "public-friendly" released items and the clones of patented portions, and then change the patented portions, cry foul and litigate, or buy up/out competitors that clone or license the technologies 3. PROFIT!
Anyone used Visual Studio.NET lately? It's touted as being an amazing piece of work, written mostly in.NET compatible languages and for the.NET platform. And guess what - it's slow. It's noticeably slower than the previous Visual Studios, even the bubblegum version for web and VB developers. In comparison to the previous Visual C++, it's practically standing still.
Furthermore, it's even noticeably slower than, say, Eclipse, a comparable IDE for Java that uses a platform-independent API to native UI widgets, much like.NET does. Visual Studio is not a zippy application.
So keep it C++ but with.NET enhancements you say? Managed C++ is a bloody nightmare. It's really not practical to use it for anything other than tying native C++ code to.NET components. It's also not much easier than using COM components directly, plus you have to limit yourself to.NET management of memory, objects, exceptions, which all add extra cycles you could avoid going totally native.
We're continually fedd technologies from Microsoft that are supposed to be "the next big thing". Look at COM+. Look at ActiveX. The big thing has become old news year after year while other technologies with fewer hard corporate ties expand and proliferate. It's certainly worth learning--Microsoft is pouring the money bucket into.NET very quickly, and there's jobs to be had. Just don't buy into the hype we've been force-fed for the past two years about.NET taking over the world.
No, Virginia, there is no Santa Claus. The emperor is naked.
Is it just me, or has CT become disturbingly bitter since the infant years of Slashdot? Early article posts and their accompanying banter were fresh, clean, and invigorating. These days, everything is bad unless it's anti-DMCA or pro-amateur rocketry.
Perhaps I'm crazy, but I've been observing the change for a long time:)
Surely there is no new precedent set here for a vocal user minority tainting the image of the group. Why the bitterness?
Any amount of drag created would outweigh the power generated. You're still converting mechanical energy into electrical, which nobody can do without loss. I thought about something similar way back when: attaching windmills to cars, so that when driving you generate your own electricity. Duh...windmills create drag and reduce the efficiency of the machine causing the wind, i.e. the car or the central air system, more than the amount of energy you could generate.
Now with that said, here's another one for you: Windmills changing the course of the planet. The energy generated from windmills has to come from somewhere. To say it's free energy ignores the fact that if the windmills weren't there, the energy would go to some other use, be it cooling the earth's surface, spreading pollen, mitigating weather differences. Enough windmills could conceivably remove enough energy from the weather system to have an effect, even if it was a small effect over a long time. Case in point: weather systems can vary drastically around large metropolitan areas that create wind tunnel and dead zone effects as opposed to forests that might stand very nearby.
Some people advocate wave-based power generation. The basic idea is that a floating series of rafts, connected by generators, would produce electrical power as waves caused them to flex. Another source of free power? No. Waves aren't simply there to be harnessed...they do a lot to keep the seas well mixed, and are one of the most powerful factors in our weather system. Every generator set placed on the ocean would effect wave formation, and ultimately, the rest of the world.
Even solar power doesn't produce magical free energy...more solar energy absorbed and used on the surface of the earth means less radiated back into space. The net energy content of the Earth increases as a result of solar power. The best solar panels get damned hot, and that heat has to go somewhere. Normally, a large potion of it is sent back into space. Covering the surface of the Earth with a blanket of black solar panels would create one hell of a heating problem. Yes, I know that more efficient solar panels would create electricity more efficiently, heating up less, but the end result is the same...that efficiently-generated energy has two side effects: less sunlight is reflected back at the sky, to either proceed on into space or come back down in another location, and that electricity ultimately is used to power inefficient electronics and machinery, producing heat that would not have otherwise been produced.
The greenhouse effect would have nothing on the effect of capturing 100% of the sun's radiation to run a bunch of noisy, heat-producing machines. Energy is never destroyed or created...merely transformed.
So, in the end, we're just doomed! Hurrah!
Or perhaps we could stop turning so damned much energy into heat and noise.
I've been developing embedded Java solutions for the aj-80 and aj-100 for about 5 months now, and I must say they are nice little processors. Very fast, very solid resource management, and a solid selection of APIs.
This is another cool innovation from aJile, I hope we'll see more like this. Now if the embedded side of J2ME development would take off, the world would be a much nicer place!
You certainly are banking on Microsoft remaining benevolent toward Mono. I'm not sure why it's so hard for people to see that MS has absolutely nothing to gain from Mono becoming popular and widely used, except that it will draw people into the real.NET platform, which only runs under Windows.
Mono on Linux will always lag behind the Windows-based implementations from Microsoft, and Microsoft knows it. They've opened up the runtime, but not the class libraries that make the platform useful. The result is that Mono has to reimplement everything Microsoft has created, and try to match all the quirks, tricks, and undocumented behaviors therein. It's a losing battle.
I would love to see Mono as a viable, cross-platform,.NET-compatible deployment platform, but I truly believe it's a pipe dream. Mono could enable Microsoft's next-generation development platform, on which they are banking millions of dollars, to run without any ties to Microsoft itself. There's no way they would quietly sit by and let that happen. By keeping certain portions of the platform closed, patented, propietary, they keep their stranglehold on the whole ball of wax. People who like and become dependent on the n number of features Mono provides under Linux will very likely want the n+1 number of features that the bleeding edge Microsoft runtime and class libraries can provide. All roads in.NET lead to Microsoft.
Not to mention C# is the ugliest hodge-podge mix of C, C++, Java, and VB I could have imagined. Really guys, you don't need to change the name of keywords solely to be different. SAMENESS IS GOOD WHEN IT COMES TO CODE.
Not that I'm surprised. Anything that wants a true relational backend, much less an object-relational DBMS, much choose a REAL database.
FLAME ON!
At any rate, another portal entry brings on fits of yawns. None of the portals currently available do what people want them to, and all of them provide nearly identical feature sets. Whooop-dee-do.
Wouldn't the full LOTR be over 12 hours on completion? The first two films are already close to or greater than 3 hours in the theater, and the DVD release of TFotR is well over 3 hours. A full DVD release should be much closer to 12 hours.
I still have a shareware app on the market that brings in a couple registrations per week. Shareware was flooded in the late nineties with a whole load of crap, much of it written in VB. Probably 90% provided one tiny little feature, so you'd end up using 50 of them to provide the complete functionality of a better app. As a result, overall shareware registrations dropped dramatically -- there was a far smaller percentage of apps worth registering.
It's a testament to certain apps that they still survive well under a shareware model. Shareware certainly works, but only if you aren't charging too much and don't deliver a big ball of crap.
where it can hopefully be built into attack aircraft
Hopefully? I for one hope against hope for weapons NOT being proliferated. An impossible dream perhaps, but I'm certainly not going to hope for the opposite--that every new technology can have a quick and prolific entry into the war arena.
Guess what...war begets war. Weapons beget weapons. I'm much more interested in technology like this remaining purely defensive, rather than letting warmongers fly into any territory they like, frying their supposed enemies like so many eggs.
Comments like this sicken me. War is not cool. Killing people is not cool. Wake up.
Look, the bottom line, and the one that most people seem to ignore, is that Microsoft has been doing this crap for a long time. They're not going to suddenly "oops" and open the door to alternate platforms. The cornerstone of their market share is the fact that Windows is ubiquitous. Above ALL ELSE, they must defend that position viciously.
The idea that they would in any way allow.NET to become a portable, cross-platform, non-MS-specific platform for network and desktop applications is absolutely absurd. If it's wide open now, it's to draw in flies with honey-sweet nectar. Once the flies are stuck, the jaws will snap shut, and Microsoft will have captured them all.
In this way, not only would Microsoft have captured a significant share of the network application market, but they will have done so on the backs of open-source developers who unwittingly implemented.NET environments on competing operating systems, simultaneously validating the platform as true and viable and addicting everyone from programmers to CXOs to the nectar within.
Microsoft would not and will not allow a platform of their design and control to be used against them so easily. They didn't become the richest software company in the world by making business mistakes. To think differently is ludicrous.
I applaud the effort of developers working earnestly to provide a free.NET environment, but the costs may be more than the benefits if all they succeed in doing is giving Microsoft a leg up.
Come on now, you guys didn't really think Microsoft was going to sit back and let someone else build a free implementation of their golden goose before it was even in wide acceptance, did you? What is it about some Open Source projects that makes their fearless leaders so starry-eyed? It is perhaps surprising that Microsoft waited this long.
Microsoft still makes more off Windows sales than anything else -- don't forget that. No matter how ubiquitous Office is, Windows is the cornerstone of the Monopoly. By filing for a patent on.NET, their new platform-of-choice, they can lock out all competing implementations, either a little bit or completely, making sure that the only full.NET implementation is the one they've delivered, under Windows.
This also bodes pretty badly for.NET. If you ask me, the lawyers at Microsoft won an argument on this one. If MS really wanted to get a stranglehold on the market, they'd have waited until.NET actually had its foot in the door before filing a patent. By doing so now, before it's really even gotten out of the gate, they've doomed it to be "just another Windows-based programming platform".
Don't believe me? What shop that isn't pure Microsoft would even consider jumping onto the.NET bandwagon now? Commit all your resources to a platform that still performs more poorly than those available for higher-end, non-Wintel machines? Doubtful. The development benefits are marginal compared to Java, and native application developers will still prefer C or C++. Now that Microsoft will have a legal noose around.NET's neck, all circulation is effectively cut off.
It's a stupid move for Microsoft, if they intend to expand and defend their monopoly. It's also a move that projects like Mono and.Gnu should have seen coming a mile away. Microsoft has nothing to gain by researching, developing, and standardizing a platform that could conceivably allow network AND desktop applications to run on non-Microsoft platforms. Did Miguel et al just think Microsoft had learned the error of their ways?
Everything about this memo sounds as fake as can be. For example:
Sun complaining about the JRE support model for internal projects...THEY ARE THEY JRE SUPPORT MODEL. It would be a bit like Ford recommending people don't use Ford parts for internal work because they'd have to go to Ford to get support for them. Eh?
Listing off the memory footprint of various "demo" applications. The "Hello World" reference gives this away as totally bogus. Anyone who's used Java knows about its memory consumption. From day one people understand that it is not recommended for smaller applications. That's not the intention of Java, and it's not a recommendation or warning Sun would ever make internally. Java is excellent, perhaps better than anything else, for interoperable, server-side, cross-platform development. The claim that there are "better languages for that" is totally bogus. Show me another single language that packages object communication, database-independent persistance, compile once, reliable threading, and hundreds of other Java features, while being available on every major (and most minor) operating systems and platforms available. An external user trying to take Java down a notch (perhaps a disgruntled C++ developer?) would almost certainly point at the size of a "Hello World" application. BTW, guess what: Hello World compiles to a couple kB of Java code. If the platform uses 9M for a small program, that's not part of Hello World's memory footprint. How much memory does a compiled C program take (including all external libraries and the kernel itself) compared to its compiled size? The holistic difference is striking.
The numbers about startup time and third-party application time. Why on earth would Solaris care if TogetherJ takes a long time to start up? If TogetherJ is written badly enough that it consumes 900MB of memory, then it's a failing of Togethersoft, not of Java. Too many Java developers have fallen into the trap of "memory is cheap, objects are garbage collected" and use truly gross algorithms in their software. A little common sense would reduce the footprint of some of these applications down to much more manageable levels. One should look at Java applications that do extremely well with regards to memory management, for example JBoss 3 and Eclipse. Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system. JBoss is a fully J2EE-compliant container, and starts up into about 32M on my machine. Compare that with other offerings.
Backward compatibility across minor releases. Everyone familiar with Java knows that 1.2, 1.3, 1.4, are as far from "minor releases" as they could possibly be. There's absolutely nothing "minor" about them. The small compatibility issues that are listed in this document are almost certainly issues someone would face if they move from one level to the next and use deeper features of the JVM. The concern about Class.fields() is ludicrous. It changed after 1.1 (about FIVE YEARS AGO, PEOPLE) and hasn't changed since. The other two complaints are about UI behavior changing across major versions (1.3 to 1.4 and 1.2.2 to 1.3.1). Guess what...they're going to introduce improvements into UI behavior to improve the performance of the platform's UI as a whole. The interfaces did not change. The contracts between classes did not change. If someone's tables ended up looking a little different (boo-hoo, perhaps this is a Java UI developer who's out of his league) then you either recommend one major revision or another, or you format your UI in such a way as to prevent problems (not a difficult thing to do with Java's UI support). These gripes more than any others point to this being a fake: Everyone outside of Sun knows that 1.2->1.3->1.4 are not "minor revisions" and would never treat them as such. There's NO WAY Sun would refer to them in that way.
Other issues are also well known to Java developers, and are easiliy avoided:
JNI is unstable: Well duh...anytime you link out of the JVM you are dependent on external code for reliability. If the external code bloze or doesn't behave, guess what...you crash. Sun recommends not using JNI unless there's no other way to solve a problem, and wouldn't list this as a fault.
Vitria: 450+ containers? What in holy hell are they doing with 450+ containers? Running a single component in each one? No reasonable architecture would EVER use this many JVMs on a single machine. The person who recommended this should be shot, and the person who wrote this obviously fake memo is looking for worst case scenarios to support their arguments. Regardless of Sun's marketing, companies with alternative languages and platforms would not be buying on if the platform itself wasn't so powerful. Would IBM have blown $1B+ developing Eclipse if they thought Java had unsolvable issues? Not bloody likely.
JSSE referred to like a distant cousin: JSSE is Java's Security Extensions, and although the article is correct (it was formerly a plugin, now included in J2EE) it is referred to as "an external module called JSSE" and never once listed as a security extension. Does the author of this "memo" not know a primary, core technology that Java uses for security? Someone is extremely ill-informed, or has nothing whatsoever to do with Java.
Ultimately, even if this does turn out to be an internal memo, I'd wager it's from a lower-level developer on the C++ side of the company that is angry (or worried) about the push towards Java-based applications over native languages. You can bet your ass this isn't a company-wide, high-level memo, because it's simply not true. How about this scenario:
1. Internal Sun employee NOT involved in Java becomes disgruntled about getting fewer new projects and more maintenance and support work. 2. Employee starts to monkey around with Java, either to nitpick well-known faults and flaws or to gain a better understanding, hopefully to get an "in" on new Java-based projects 3. Employee finds enough nitpicking details to write an "internal memo" recommending Java not be used, or get frustrated that they can't learn the entire language in a day and does the same. 4. Employee writes said "internal memo", hoping to stir up some discussion 5. After the employee's claims are shot down, much like I did above, the employee gets even more frustrated 6. Employee "leaks" the memo to stir up bad press for employer. Since the memo appears on a site where "accidentally" leaked memos appear, employee can feign ignorance.
Everyone jumps to conclusions on these things. Don't believe everything you read. Java is a spectular language...anyone who has used it for any length of time knows that. The people who have never used it on a real-world project are routinely its biggest critics.
Now they just have to figure out how to shrink a power source down small enough to match. With this technology, the size of a battery would be a limiting factor in thickness. Not only that, but a battery contains toxic chemicals that would be paired side by side with one of the most thrown away materials of our day: paper. This might also throw a wrench into recycling..not only because of the battery but because of the material(s) used for the processor and electronics.
Still pretty cool thought, but perhaps a warning "do not burn this computerized paper in your fireplace" would be in order so people aren't getting battery bits shot into their eyes.
There's a number of ways one can produce these shapes using a series of ropes and stakes. The fact that these images are perfect geometric shapes actually HELPS prove that they're manmade. Regardless of how complex they are, there are simple geometric principles one can use to produce them. Consider the alternative...if they were not perfect geometric shapes, i.e. shapes that could not be produced through some simple mathematical formulation, but still perfectly created, would they be less or more convincing?
The pictures are even more obvious (including the ASCII-encoded "digital disc". If the intent is to communicate an image, there would be much better ways to do so. And ASCII encoding? In perfect English? Why not just write the damned letters? Encodinging it "digitally" makes it seem less obvious...people with little knowledge of ASCII or character codings go "ooh" and "ahh" and say it must be real. Gimme a break.
2. iron spheres
Please, I have a bucket of these in my garage. They're called various names, including "microspheres" and are used in various industries as a substrate, deburring mechanism, polishing medium, abrasive medium, etc. Under a microscope, they can be as small as a couple hundred microns. Try here.
3. Radioactive, cooked plants
Radioactive microspheres are often used for delivering radioactive isotopes for medical applications. Try here.
As for the cooking, I'd have to see it for myself, but a quick torch at low temparature applied to a plant causes the sugars near the surface to quickly carmelize, and the plant to become pliable without severe damage to the core of the plant. The results afterwards, however, are a permanent change in the shape of the plant, and reduced growth (but the plant is not killed). In the presence of water, the plants can also be softened with less damage to the stem. Again, I don't know for sure:) Plants are pretty resilient things though.
4. odd performance from aircraft
Dunno about this one. I'd be interested in a double-blind study to confirm this is the case, and I haven't seen any definitive evidence saying this is true. Have someone fly over it without knowing it was there and report problems, and maybe we'll have a winner. If someone sees the circle or knows it's there BEFORE reporting problems, all bets are off. We are easily influence by things we want to believe. "There's a crop circle, I bet my instruments are going to go wacky....THEY ARE!!!"
I've always had issues with calling Moore's Law a "Law". Nobody has conclusively proven it. It should instead be called "Moore's Hypothesis" or "Moore's Theorem" if you're more optimistic...
I already wrote to CNN.com and told them I would never EVER pay for their stupid video subscription. I could almost always see the videos somewhere else, and if I couldn't, who care? The news is what I care about...video is fluff at best.
If CNN.com goes away, boo-hoo. There's 100 other services out there that provide news for free, some without the capitalist slant. All these companies that are feeling the pinch of the slowing economy and the remains of the burst bubble break my heart. Cry me a river.
What nobody paid attention to back when the bubble was riding high was that surprise surprise, just because the Internet has arrived doesn't mean there's more consumers. The consumers just move from one product to another. It's akin to thermodynamics: demand cannot be created nor destroyed, only changed from one form of demand to another. Sites that don't provide anything new or remarkably different from everyone else are not going to survive.
Originality is what drives the best sites. Google is a shockingly good search engine...Yahoo and Amazon are very simple interfaces to many different types of content (stores, news, searching, auctions) and of course eBay is simply the de-facto standard for buying and selling items online. Provide something new and original, or stop whining.
I'd like to add that some of the problems of X are problems of Linux in general - too many configurations, too few of them documented well. There's 101 ways one could speed up an X server, but I've got better things to do with my time. For anyone who doesn't love endlessly tweaking their OS, or for anyone that thinks the OS should be supporting them rather than hindering them, Linux can be a nightmare.
I've been running Linux and other UN*X's since back when I loaded Slackware onto a stack of 40-odd floppies to install it (CD burning? Science fiction!), and I've backed it all the way. I still back it whenever possible, but unfortunately, the problems I had to apologize for years ago are still mostly there. Some configurations have improved, sometimes with the help of other applications, while many more have not. In X's case, most of the distros do a superb job of getting it up and going, often very close to optimally. In GNOME or KDE's case, they'll get up and running ok, but configuration frailty means that a slip-up or badly placed bug can cause the whole thing to come tumbling down.
I run Windows on my desktops now - not because I love it or because I hate Linux (both false), but because it just works. It's not pretty, it's not open, and it's not what I want to run, but it's the simplest option when I just want to get some other shit done. If I had Macs I'd run OS X, not Linux, for the same reasons. I've grown tired of hunting for configuration file SuperNifty.conf buried somewhere different on every platform. I don't care if I can enable anti-aliased buttons in SuperNifty! If AA buttons make me more productive, turn the damn things on. If I should have the option of turning it on or off, make it simple for me to do so.
In the open-source world, too many projects seem to think the community owes them a debt. Why make an application easier to use when it works fine already? Because users, not developers or designers, decide the course of software evolution. Survival of the fittest applies here: bad software falls by the wayside, good software propagates. If you can't make a piece of software usable by and useful to more people than competing software - you are going to lose.
I will certainly look into that presentation. I'm not trying to mindlessly bash X...I honestly wish it wasn't a problem. I don't want to be stuck on Windows any more than you, but going from a sports car to a regular car, in terms of responsiveness and speed, is not generally enjoyable. Even if the difference is small, it's there.
I also don't mean it to sound like I think C/S is the root of all X's problems--there's certainly plenty of others. I do, however, mean to say that there's too many layers between an X app and the hardware it is trying to access...even with all the fancy additions.
Measured statistics have shown that X is actually faster at some operatons (like line drawing etc) than the GDI on Windows.
Some operations. Some operations being faster does not a faster desktop make. Great, so under some circumstances, it can draw a line faster. The bottom line is that if one desktop has 5 layers of abstraction between the app and the hardware, and another has 4, the one with 4 layers has a much better chance of winning the race.
I guess no Microsoft app ever crashes either?
I never said that. See my other posting for why I feel X apps are especially prone to failure. Simply put, it's those lovely abstractions...they're never perfect, and if superb layer 5 depends on buggy layer 4, layers 6+ are hurt by it.
This sounds more like a "my favourite bug/feature isn't fixed yet" rant
No. I've been in the belly of the beast, and I'm guilty of doing the same thing. If a bug or problem is particular difficult to fix, and there's super-cool fancy-daddy super-wow graphics work that also needs to be done, I have seen very few people that choose the bug. Of course there's some people out there who live for that, but they're not a majority. Generally, open-source projects charge forward with new features and new enhancements while leaving many critical flaws for later. In this respect, they're the same as what Microsoft does - get the software out the door, make sure it's pretty, and try to get some good press. The truth is often far different.
X has nothing to do with polish OK, and FYI both KDE and GNOME have oodles of corporate funding.
Let's see some numbers on how much funding GNOME and KDE have versus corporate alternatives. Let's see how many man-hours are put into all the choices. As far as I know, there's never been any study into either statistic. I know you'll say that man-hours and money are not the key to good software, but relying on developers to work in their spare time, or pitting a group of n developers against a group of 50n developers in creating a complex system is painful. Throwing more developers at a problem does not usually help it, but providing more resources from the start can mean the problem doesn't show up at all. Note I say RESOURCES.
I've tried DirectFB, and yes, it's slow. X hitting the FB directly is also slow. Neither are what I want. The FB is for platform-independent access to video, as directly as possible. It's great that it's there, it's great that it's enabling so many systems, but it's not going to help performance, and I don't think that's its purpose.
Granted, buggy apps crash wherever they are. I do, however, think that X apps, being necessarily more complex than CLI apps, are prone to many more bugs. Writing a GUI app well is hard. Writing a toolkit to run that GUI app is hard. Writing all the other libraries and services to support a full-featured desktop, based on those GUI apps and toolkits is hard * hard. X, while providing a non-specific platform for windowing, has not provided any indication as to how those windows should look or behave. That means every app running in X relies on a MOUNTAIN of libraries. One critical bug in one of those library (which are developed by groups all over the world that all have their own way of doing things and their own plans) means the app has a critical bug. Multiply that by all the leaky abstractions inherent in layers upon layers of libraries, and you've got a big, fat mess.
This isn't to say X apps couldn't be great. With well-defined, well-documented, and well-standardized development practices, interfaces, and protocols, the leaks between layers would certainly be lessened. Right now, however, I run apps under X holding my breath. I've had critical applications crash far too often (usually losing work in the progress) to trust them anymore.
And you know what? vi doesn't crash. Why? Because it's not piled upon a hundred layers of libraries that all have their own problems. Writing GUI desktop applications is hard. Writing them under X is monumentally hard.
Slashdot Mirror
No language is without flaws. In C, the golden boy among die-hard geeks, you spend as much time managing memory and pointers as you do creating application logic. C++ saves many of those problems while introducing new pseudo-OO constructs that have peculiar and arcane rules governing their use. C# opts to provide far too many keywords for nearly identical behaviors and then renames half of them to look "new". Perl is terribly powerful, but can become obfuscated and impossible to maintain if used most efficiently. VB glosses over so many basic programming principles that its users waste time and CPU cycles re-reinventing the wheel. I can't say I know what's wrong with many others because I haven't used them, but no language is perfect.
That said, Java has terrific benefits and some deadly flaws. JSPs, for one, are a mess. Embedding code for even such simple tasks as displaying dynamic fields is error-prone and difficult to maintain. Add to that the fact that so many JSP developers leave reams of business code in the JSPs themselves, and the hackish nature of JSP comes to light. This is not, however, a simple Java problem, and it plagues any similar templating languages. I have seen some ASP pages that were phenomenally large. Bad practice is bad practice, irregardless of where it occurs.
Java also suffers, as many know, from serious memory issues. In the rush to provide a single language platform for applications across all aspects of software engineering, Java tries to do too much in too many places. Java can be embedded inside phones for small Internet clients and video games, or loaded onto the largest servers for massive Java-based enterprise integration applications. It does both of those things exceedingly well, providing powerful abstractions at both micro and macro levels. The grey area in the middle is where most people stumble. Drawing the line between "enterprise" and "standard" code libraries is very difficult, and many "enterprise" features remain in the "standard" version of Java, adding to the bloat. What's worse, only within the last couple years has the question of memory consumption begun to be addressed in earnest by Sun engineers. There are many lights ahead, however, be it the improved base memory handling in Java 1.5, or the eventual integration of Apple's VM-sharing innovations into the Sun Java proper.
Java being staticly type has other problematic side-effects; namely, as data and systems outside an application change or as the application as a whole needs to grow and adapt to new requirements, single small changes in a few classes can explode into massive alterations throughout the system. Again, much of this can be mitigated with rigid adherence to preferred OO practices. If those practices are not enough, there are a number of freely-available APIs and libraries to allow for more dynamicity and looser coupling between tiers, almost certainly easing these upward transitions.
At the end of the day, any software development group wants the tool that gets the job done. No project I've ever been associated with chose Java because of market hype or buzzword psychosis. They chose Java because it presented the most complete set of enterprise service abstractions in a single platform, without needing vast amounts of glue code to aggregate them into a single, homogeneous enterprise application. I have also never been on a Java project that failed, although many stumbled along the way. Java is not market-successful simply because it is hyped, or because it is trendy, or because I say so. It is successful because it provides developers more tools in a single toolbox than other comparable languages.
Interfaces are only half of the story. Interfaces without implementations are absolutely worthless. Microsoft owns the "standard" implementation of all the interfaces they've published. No matter how well documented, no matter how clear the contract, all implementations will have peripheral, unspecified behavior. In Microsoft's case, perhaps it will interface with the OS primitives better because of information only Microsoft knows. Perhaps it will interface better with Microsoft products because of intimate knowledge of unpublished shortcuts only Microsoft knows. There's an endless number of ways that Microsoft can change their implementation and result in interoperability problems with other non-Microsoft implementations.
.NET are still Microsoft proprietary and will have to be cloned. Microsoft doesn't have to make any guarantees about clones working the same way their original implementations do. Not only that, but the fact that these are interfaces says nothing for the fact that Microsoft can add features to their .NET without providing any information or support to alternative implementations. What will Mono do if Microsoft doesn't standardize the next version of C#, or just adds additional features across the board without publishing information or providing support to implement them? Fork .NET?
.NET over time, or feeding information on them just a bit too slowly to alternative implementations won't hurt Windows-based .NET developers one bit, but it certainly will cause non-Windows-based .NET developers to consider moving. History has shown this is EXACTLY how Microsoft works.
You also seem to ignore many of the other points...large portions of
You forget the key principle behind which Microsoft has managed to succeed: Embrace and extend. They've done it before to other open standards that they had no control over. You're trying to tell me they won't do the same thing when they DO control the items that are standardized?
Selectively closing revised portions of
- Charlie
Mono is a great piece of software. That said, the only benefits I can see to having it exist are to Microsoft and Ximian. I don't understand the naivete that makes people think "Microsoft won't screw us this time." As Miguel has admitted in the Mono FAQ referenced in another reply, large portions of .NET are still proprietary Microsoft creations. Sure, you can port them, but then Microsoft can just change them or add features, and you're always a step behind. If they're feeling really pushy, they can push for legal action.
.NET are such a small part of the whole platform as to be laughable. Sure, the language is standard. Whoopty-freaking-do. As any developer knows, just having a standardized language does not a development platform make. And in this case, a FOSS-based .NET is far, far from being a safe, platform-independent enterprise application environment.
.NET such a big new item these days? Because Microsoft's bully tactics haven't given them a decisive share of Internet development traffic. Even the name .NET is created to ensnare CTOs into thinking this is the way to go. At the end of the day, Microsoft is not a company that gives away technology and opens the door to alternative operating systems and development platforms. If they open the door at all, it's only to lock you in to one of their proprietary technologies.
It doesn't really stop there. The standardized portions of
It comes down to a simple truth: Microsoft does what's best for MICROSOFT. Everything they do is focused in increasing revenues and expanding market share. Why is
Open source will not save your soul here. Unless you have some magical codebase that's going to automatically include the new features Microsoft is certain to release in their platform-specific implementation, the FOSS version will always, ALWAYS be a step behind...and that step will probably be really big. So what if the source is open? It's going to be feature-incomplete, last month's/year's technology, and possibly legally questionable. Sounds like a winning combination for your core mission-critical apps. Sounds like a certain path to the original Creator of said platform...a path away from FOSS.
Please, do not be fooled. This recipe has been repeated again and again.
1. Release semi-standardized software, api, or development platform while holding onto patents for large, key portions
2. Wait until a large community builds around those "public-friendly" released items and the clones of patented portions, and then change the patented portions, cry foul and litigate, or buy up/out competitors that clone or license the technologies
3. PROFIT!
Once again, everyone has forgotten #2.
- Charlie
Anyone used Visual Studio .NET lately? It's touted as being an amazing piece of work, written mostly in .NET compatible languages and for the .NET platform. And guess what - it's slow. It's noticeably slower than the previous Visual Studios, even the bubblegum version for web and VB developers. In comparison to the previous Visual C++, it's practically standing still.
.NET does. Visual Studio is not a zippy application.
.NET enhancements you say? Managed C++ is a bloody nightmare. It's really not practical to use it for anything other than tying native C++ code to .NET components. It's also not much easier than using COM components directly, plus you have to limit yourself to .NET management of memory, objects, exceptions, which all add extra cycles you could avoid going totally native.
.NET very quickly, and there's jobs to be had. Just don't buy into the hype we've been force-fed for the past two years about .NET taking over the world.
Furthermore, it's even noticeably slower than, say, Eclipse, a comparable IDE for Java that uses a platform-independent API to native UI widgets, much like
So keep it C++ but with
We're continually fedd technologies from Microsoft that are supposed to be "the next big thing". Look at COM+. Look at ActiveX. The big thing has become old news year after year while other technologies with fewer hard corporate ties expand and proliferate. It's certainly worth learning--Microsoft is pouring the money bucket into
No, Virginia, there is no Santa Claus. The emperor is naked.
Is it just me, or has CT become disturbingly bitter since the infant years of Slashdot? Early article posts and their accompanying banter were fresh, clean, and invigorating. These days, everything is bad unless it's anti-DMCA or pro-amateur rocketry.
:)
Perhaps I'm crazy, but I've been observing the change for a long time
Surely there is no new precedent set here for a vocal user minority tainting the image of the group. Why the bitterness?
Perhaps CT needs a hug!
Any amount of drag created would outweigh the power generated. You're still converting mechanical energy into electrical, which nobody can do without loss. I thought about something similar way back when: attaching windmills to cars, so that when driving you generate your own electricity. Duh...windmills create drag and reduce the efficiency of the machine causing the wind, i.e. the car or the central air system, more than the amount of energy you could generate.
Now with that said, here's another one for you: Windmills changing the course of the planet. The energy generated from windmills has to come from somewhere. To say it's free energy ignores the fact that if the windmills weren't there, the energy would go to some other use, be it cooling the earth's surface, spreading pollen, mitigating weather differences. Enough windmills could conceivably remove enough energy from the weather system to have an effect, even if it was a small effect over a long time. Case in point: weather systems can vary drastically around large metropolitan areas that create wind tunnel and dead zone effects as opposed to forests that might stand very nearby.
Some people advocate wave-based power generation. The basic idea is that a floating series of rafts, connected by generators, would produce electrical power as waves caused them to flex. Another source of free power? No. Waves aren't simply there to be harnessed...they do a lot to keep the seas well mixed, and are one of the most powerful factors in our weather system. Every generator set placed on the ocean would effect wave formation, and ultimately, the rest of the world.
Even solar power doesn't produce magical free energy...more solar energy absorbed and used on the surface of the earth means less radiated back into space. The net energy content of the Earth increases as a result of solar power. The best solar panels get damned hot, and that heat has to go somewhere. Normally, a large potion of it is sent back into space. Covering the surface of the Earth with a blanket of black solar panels would create one hell of a heating problem. Yes, I know that more efficient solar panels would create electricity more efficiently, heating up less, but the end result is the same...that efficiently-generated energy has two side effects: less sunlight is reflected back at the sky, to either proceed on into space or come back down in another location, and that electricity ultimately is used to power inefficient electronics and machinery, producing heat that would not have otherwise been produced.
The greenhouse effect would have nothing on the effect of capturing 100% of the sun's radiation to run a bunch of noisy, heat-producing machines. Energy is never destroyed or created...merely transformed.
So, in the end, we're just doomed! Hurrah!
Or perhaps we could stop turning so damned much energy into heat and noise.
Food for thought!
I've been developing embedded Java solutions for the aj-80 and aj-100 for about 5 months now, and I must say they are nice little processors. Very fast, very solid resource management, and a solid selection of APIs.
This is another cool innovation from aJile, I hope we'll see more like this. Now if the embedded side of J2ME development would take off, the world would be a much nicer place!
You certainly are banking on Microsoft remaining benevolent toward Mono. I'm not sure why it's so hard for people to see that MS has absolutely nothing to gain from Mono becoming popular and widely used, except that it will draw people into the real .NET platform, which only runs under Windows.
.NET-compatible deployment platform, but I truly believe it's a pipe dream. Mono could enable Microsoft's next-generation development platform, on which they are banking millions of dollars, to run without any ties to Microsoft itself. There's no way they would quietly sit by and let that happen. By keeping certain portions of the platform closed, patented, propietary, they keep their stranglehold on the whole ball of wax. People who like and become dependent on the n number of features Mono provides under Linux will very likely want the n+1 number of features that the bleeding edge Microsoft runtime and class libraries can provide. All roads in .NET lead to Microsoft.
Mono on Linux will always lag behind the Windows-based implementations from Microsoft, and Microsoft knows it. They've opened up the runtime, but not the class libraries that make the platform useful. The result is that Mono has to reimplement everything Microsoft has created, and try to match all the quirks, tricks, and undocumented behaviors therein. It's a losing battle.
I would love to see Mono as a viable, cross-platform,
Not to mention C# is the ugliest hodge-podge mix of C, C++, Java, and VB I could have imagined. Really guys, you don't need to change the name of keywords solely to be different. SAMENESS IS GOOD WHEN IT COMES TO CODE.
Not that I'm surprised. Anything that wants a true relational backend, much less an object-relational DBMS, much choose a REAL database.
FLAME ON!
At any rate, another portal entry brings on fits of yawns. None of the portals currently available do what people want them to, and all of them provide nearly identical feature sets. Whooop-dee-do.
Wouldn't the full LOTR be over 12 hours on completion? The first two films are already close to or greater than 3 hours in the theater, and the DVD release of TFotR is well over 3 hours. A full DVD release should be much closer to 12 hours.
I still have a shareware app on the market that brings in a couple registrations per week. Shareware was flooded in the late nineties with a whole load of crap, much of it written in VB. Probably 90% provided one tiny little feature, so you'd end up using 50 of them to provide the complete functionality of a better app. As a result, overall shareware registrations dropped dramatically -- there was a far smaller percentage of apps worth registering.
It's a testament to certain apps that they still survive well under a shareware model. Shareware certainly works, but only if you aren't charging too much and don't deliver a big ball of crap.
where it can hopefully be built into attack aircraft
Hopefully? I for one hope against hope for weapons NOT being proliferated. An impossible dream perhaps, but I'm certainly not going to hope for the opposite--that every new technology can have a quick and prolific entry into the war arena.
Guess what...war begets war. Weapons beget weapons. I'm much more interested in technology like this remaining purely defensive, rather than letting warmongers fly into any territory they like, frying their supposed enemies like so many eggs.
Comments like this sicken me. War is not cool. Killing people is not cool. Wake up.
Great review. I always like my hardware reviews crammed full of marketing claptrap from start to finish!
Look, the bottom line, and the one that most people seem to ignore, is that Microsoft has been doing this crap for a long time. They're not going to suddenly "oops" and open the door to alternate platforms. The cornerstone of their market share is the fact that Windows is ubiquitous. Above ALL ELSE, they must defend that position viciously.
.NET to become a portable, cross-platform, non-MS-specific platform for network and desktop applications is absolutely absurd. If it's wide open now, it's to draw in flies with honey-sweet nectar. Once the flies are stuck, the jaws will snap shut, and Microsoft will have captured them all.
.NET environments on competing operating systems, simultaneously validating the platform as true and viable and addicting everyone from programmers to CXOs to the nectar within.
.NET environment, but the costs may be more than the benefits if all they succeed in doing is giving Microsoft a leg up.
The idea that they would in any way allow
In this way, not only would Microsoft have captured a significant share of the network application market, but they will have done so on the backs of open-source developers who unwittingly implemented
Microsoft would not and will not allow a platform of their design and control to be used against them so easily. They didn't become the richest software company in the world by making business mistakes. To think differently is ludicrous.
I applaud the effort of developers working earnestly to provide a free
Come on now, you guys didn't really think Microsoft was going to sit back and let someone else build a free implementation of their golden goose before it was even in wide acceptance, did you? What is it about some Open Source projects that makes their fearless leaders so starry-eyed? It is perhaps surprising that Microsoft waited this long.
.NET, their new platform-of-choice, they can lock out all competing implementations, either a little bit or completely, making sure that the only full .NET implementation is the one they've delivered, under Windows.
.NET. If you ask me, the lawyers at Microsoft won an argument on this one. If MS really wanted to get a stranglehold on the market, they'd have waited until .NET actually had its foot in the door before filing a patent. By doing so now, before it's really even gotten out of the gate, they've doomed it to be "just another Windows-based programming platform".
.NET bandwagon now? Commit all your resources to a platform that still performs more poorly than those available for higher-end, non-Wintel machines? Doubtful. The development benefits are marginal compared to Java, and native application developers will still prefer C or C++. Now that Microsoft will have a legal noose around .NET's neck, all circulation is effectively cut off.
.Gnu should have seen coming a mile away. Microsoft has nothing to gain by researching, developing, and standardizing a platform that could conceivably allow network AND desktop applications to run on non-Microsoft platforms. Did Miguel et al just think Microsoft had learned the error of their ways?
Microsoft still makes more off Windows sales than anything else -- don't forget that. No matter how ubiquitous Office is, Windows is the cornerstone of the Monopoly. By filing for a patent on
This also bodes pretty badly for
Don't believe me? What shop that isn't pure Microsoft would even consider jumping onto the
It's a stupid move for Microsoft, if they intend to expand and defend their monopoly. It's also a move that projects like Mono and
Everything about this memo sounds as fake as can be. For example:
Sun complaining about the JRE support model for internal projects...THEY ARE THEY JRE SUPPORT MODEL. It would be a bit like Ford recommending people don't use Ford parts for internal work because they'd have to go to Ford to get support for them. Eh?
Listing off the memory footprint of various "demo" applications. The "Hello World" reference gives this away as totally bogus. Anyone who's used Java knows about its memory consumption. From day one people understand that it is not recommended for smaller applications. That's not the intention of Java, and it's not a recommendation or warning Sun would ever make internally. Java is excellent, perhaps better than anything else, for interoperable, server-side, cross-platform development. The claim that there are "better languages for that" is totally bogus. Show me another single language that packages object communication, database-independent persistance, compile once, reliable threading, and hundreds of other Java features, while being available on every major (and most minor) operating systems and platforms available. An external user trying to take Java down a notch (perhaps a disgruntled C++ developer?) would almost certainly point at the size of a "Hello World" application. BTW, guess what: Hello World compiles to a couple kB of Java code. If the platform uses 9M for a small program, that's not part of Hello World's memory footprint. How much memory does a compiled C program take (including all external libraries and the kernel itself) compared to its compiled size? The holistic difference is striking.
The numbers about startup time and third-party application time. Why on earth would Solaris care if TogetherJ takes a long time to start up? If TogetherJ is written badly enough that it consumes 900MB of memory, then it's a failing of Togethersoft, not of Java. Too many Java developers have fallen into the trap of "memory is cheap, objects are garbage collected" and use truly gross algorithms in their software. A little common sense would reduce the footprint of some of these applications down to much more manageable levels. One should look at Java applications that do extremely well with regards to memory management, for example JBoss 3 and Eclipse. Eclipse provides one of the best, cleanest, well designed Java IDEs out there, and starts up into around 25M on my system. JBoss is a fully J2EE-compliant container, and starts up into about 32M on my machine. Compare that with other offerings.
Backward compatibility across minor releases. Everyone familiar with Java knows that 1.2, 1.3, 1.4, are as far from "minor releases" as they could possibly be. There's absolutely nothing "minor" about them. The small compatibility issues that are listed in this document are almost certainly issues someone would face if they move from one level to the next and use deeper features of the JVM. The concern about Class.fields() is ludicrous. It changed after 1.1 (about FIVE YEARS AGO, PEOPLE) and hasn't changed since. The other two complaints are about UI behavior changing across major versions (1.3 to 1.4 and 1.2.2 to 1.3.1). Guess what...they're going to introduce improvements into UI behavior to improve the performance of the platform's UI as a whole. The interfaces did not change. The contracts between classes did not change. If someone's tables ended up looking a little different (boo-hoo, perhaps this is a Java UI developer who's out of his league) then you either recommend one major revision or another, or you format your UI in such a way as to prevent problems (not a difficult thing to do with Java's UI support). These gripes more than any others point to this being a fake: Everyone outside of Sun knows that 1.2->1.3->1.4 are not "minor revisions" and would never treat them as such. There's NO WAY Sun would refer to them in that way.
Other issues are also well known to Java developers, and are easiliy avoided:
JNI is unstable: Well duh...anytime you link out of the JVM you are dependent on external code for reliability. If the external code bloze or doesn't behave, guess what...you crash. Sun recommends not using JNI unless there's no other way to solve a problem, and wouldn't list this as a fault.
Vitria: 450+ containers? What in holy hell are they doing with 450+ containers? Running a single component in each one? No reasonable architecture would EVER use this many JVMs on a single machine. The person who recommended this should be shot, and the person who wrote this obviously fake memo is looking for worst case scenarios to support their arguments. Regardless of Sun's marketing, companies with alternative languages and platforms would not be buying on if the platform itself wasn't so powerful. Would IBM have blown $1B+ developing Eclipse if they thought Java had unsolvable issues? Not bloody likely.
JSSE referred to like a distant cousin: JSSE is Java's Security Extensions, and although the article is correct (it was formerly a plugin, now included in J2EE) it is referred to as "an external module called JSSE" and never once listed as a security extension. Does the author of this "memo" not know a primary, core technology that Java uses for security? Someone is extremely ill-informed, or has nothing whatsoever to do with Java.
Ultimately, even if this does turn out to be an internal memo, I'd wager it's from a lower-level developer on the C++ side of the company that is angry (or worried) about the push towards Java-based applications over native languages. You can bet your ass this isn't a company-wide, high-level memo, because it's simply not true. How about this scenario:
1. Internal Sun employee NOT involved in Java becomes disgruntled about getting fewer new projects and more maintenance and support work.
2. Employee starts to monkey around with Java, either to nitpick well-known faults and flaws or to gain a better understanding, hopefully to get an "in" on new Java-based projects
3. Employee finds enough nitpicking details to write an "internal memo" recommending Java not be used, or get frustrated that they can't learn the entire language in a day and does the same.
4. Employee writes said "internal memo", hoping to stir up some discussion
5. After the employee's claims are shot down, much like I did above, the employee gets even more frustrated
6. Employee "leaks" the memo to stir up bad press for employer. Since the memo appears on a site where "accidentally" leaked memos appear, employee can feign ignorance.
Everyone jumps to conclusions on these things. Don't believe everything you read. Java is a spectular language...anyone who has used it for any length of time knows that. The people who have never used it on a real-world project are routinely its biggest critics.
Now they just have to figure out how to shrink a power source down small enough to match. With this technology, the size of a battery would be a limiting factor in thickness. Not only that, but a battery contains toxic chemicals that would be paired side by side with one of the most thrown away materials of our day: paper. This might also throw a wrench into recycling..not only because of the battery but because of the material(s) used for the processor and electronics.
Still pretty cool thought, but perhaps a warning "do not burn this computerized paper in your fireplace" would be in order so people aren't getting battery bits shot into their eyes.
1. Nearly perfect geometric shapes
:) Plants are pretty resilient things though.
There's a number of ways one can produce these shapes using a series of ropes and stakes. The fact that these images are perfect geometric shapes actually HELPS prove that they're manmade. Regardless of how complex they are, there are simple geometric principles one can use to produce them. Consider the alternative...if they were not perfect geometric shapes, i.e. shapes that could not be produced through some simple mathematical formulation, but still perfectly created, would they be less or more convincing?
The pictures are even more obvious (including the ASCII-encoded "digital disc". If the intent is to communicate an image, there would be much better ways to do so. And ASCII encoding? In perfect English? Why not just write the damned letters? Encodinging it "digitally" makes it seem less obvious...people with little knowledge of ASCII or character codings go "ooh" and "ahh" and say it must be real. Gimme a break.
2. iron spheres
Please, I have a bucket of these in my garage. They're called various names, including "microspheres" and are used in various industries as a substrate, deburring mechanism, polishing medium, abrasive medium, etc. Under a microscope, they can be as small as a couple hundred microns. Try here.
3. Radioactive, cooked plants
Radioactive microspheres are often used for delivering radioactive isotopes for medical applications. Try here.
As for the cooking, I'd have to see it for myself, but a quick torch at low temparature applied to a plant causes the sugars near the surface to quickly carmelize, and the plant to become pliable without severe damage to the core of the plant. The results afterwards, however, are a permanent change in the shape of the plant, and reduced growth (but the plant is not killed). In the presence of water, the plants can also be softened with less damage to the stem. Again, I don't know for sure
4. odd performance from aircraft
Dunno about this one. I'd be interested in a double-blind study to confirm this is the case, and I haven't seen any definitive evidence saying this is true. Have someone fly over it without knowing it was there and report problems, and maybe we'll have a winner. If someone sees the circle or knows it's there BEFORE reporting problems, all bets are off. We are easily influence by things we want to believe. "There's a crop circle, I bet my instruments are going to go wacky....THEY ARE!!!"
I've always had issues with calling Moore's Law a "Law". Nobody has conclusively proven it. It should instead be called "Moore's Hypothesis" or "Moore's Theorem" if you're more optimistic...
I already wrote to CNN.com and told them I would never EVER pay for their stupid video subscription. I could almost always see the videos somewhere else, and if I couldn't, who care? The news is what I care about...video is fluff at best.
If CNN.com goes away, boo-hoo. There's 100 other services out there that provide news for free, some without the capitalist slant. All these companies that are feeling the pinch of the slowing economy and the remains of the burst bubble break my heart. Cry me a river.
What nobody paid attention to back when the bubble was riding high was that surprise surprise, just because the Internet has arrived doesn't mean there's more consumers. The consumers just move from one product to another. It's akin to thermodynamics: demand cannot be created nor destroyed, only changed from one form of demand to another. Sites that don't provide anything new or remarkably different from everyone else are not going to survive.
Originality is what drives the best sites. Google is a shockingly good search engine...Yahoo and Amazon are very simple interfaces to many different types of content (stores, news, searching, auctions) and of course eBay is simply the de-facto standard for buying and selling items online. Provide something new and original, or stop whining.
This is my favorite reply.
I'd like to add that some of the problems of X are problems of Linux in general - too many configurations, too few of them documented well. There's 101 ways one could speed up an X server, but I've got better things to do with my time. For anyone who doesn't love endlessly tweaking their OS, or for anyone that thinks the OS should be supporting them rather than hindering them, Linux can be a nightmare.
I've been running Linux and other UN*X's since back when I loaded Slackware onto a stack of 40-odd floppies to install it (CD burning? Science fiction!), and I've backed it all the way. I still back it whenever possible, but unfortunately, the problems I had to apologize for years ago are still mostly there. Some configurations have improved, sometimes with the help of other applications, while many more have not. In X's case, most of the distros do a superb job of getting it up and going, often very close to optimally. In GNOME or KDE's case, they'll get up and running ok, but configuration frailty means that a slip-up or badly placed bug can cause the whole thing to come tumbling down.
I run Windows on my desktops now - not because I love it or because I hate Linux (both false), but because it just works. It's not pretty, it's not open, and it's not what I want to run, but it's the simplest option when I just want to get some other shit done. If I had Macs I'd run OS X, not Linux, for the same reasons. I've grown tired of hunting for configuration file SuperNifty.conf buried somewhere different on every platform. I don't care if I can enable anti-aliased buttons in SuperNifty! If AA buttons make me more productive, turn the damn things on. If I should have the option of turning it on or off, make it simple for me to do so.
In the open-source world, too many projects seem to think the community owes them a debt. Why make an application easier to use when it works fine already? Because users, not developers or designers, decide the course of software evolution. Survival of the fittest applies here: bad software falls by the wayside, good software propagates. If you can't make a piece of software usable by and useful to more people than competing software - you are going to lose.
I will certainly look into that presentation. I'm not trying to mindlessly bash X...I honestly wish it wasn't a problem. I don't want to be stuck on Windows any more than you, but going from a sports car to a regular car, in terms of responsiveness and speed, is not generally enjoyable. Even if the difference is small, it's there.
I also don't mean it to sound like I think C/S is the root of all X's problems--there's certainly plenty of others. I do, however, mean to say that there's too many layers between an X app and the hardware it is trying to access...even with all the fancy additions.
Measured statistics have shown that X is actually faster at some operatons (like line drawing etc) than the GDI on Windows.
Some operations. Some operations being faster does not a faster desktop make. Great, so under some circumstances, it can draw a line faster. The bottom line is that if one desktop has 5 layers of abstraction between the app and the hardware, and another has 4, the one with 4 layers has a much better chance of winning the race.
I guess no Microsoft app ever crashes either?
I never said that. See my other posting for why I feel X apps are especially prone to failure. Simply put, it's those lovely abstractions...they're never perfect, and if superb layer 5 depends on buggy layer 4, layers 6+ are hurt by it.
This sounds more like a "my favourite bug/feature isn't fixed yet" rant
No. I've been in the belly of the beast, and I'm guilty of doing the same thing. If a bug or problem is particular difficult to fix, and there's super-cool fancy-daddy super-wow graphics work that also needs to be done, I have seen very few people that choose the bug. Of course there's some people out there who live for that, but they're not a majority. Generally, open-source projects charge forward with new features and new enhancements while leaving many critical flaws for later. In this respect, they're the same as what Microsoft does - get the software out the door, make sure it's pretty, and try to get some good press. The truth is often far different.
X has nothing to do with polish OK, and FYI both KDE and GNOME have oodles of corporate funding.
Let's see some numbers on how much funding GNOME and KDE have versus corporate alternatives. Let's see how many man-hours are put into all the choices. As far as I know, there's never been any study into either statistic. I know you'll say that man-hours and money are not the key to good software, but relying on developers to work in their spare time, or pitting a group of n developers against a group of 50n developers in creating a complex system is painful. Throwing more developers at a problem does not usually help it, but providing more resources from the start can mean the problem doesn't show up at all. Note I say RESOURCES.
I've tried DirectFB, and yes, it's slow. X hitting the FB directly is also slow. Neither are what I want. The FB is for platform-independent access to video, as directly as possible. It's great that it's there, it's great that it's enabling so many systems, but it's not going to help performance, and I don't think that's its purpose.
Granted, buggy apps crash wherever they are. I do, however, think that X apps, being necessarily more complex than CLI apps, are prone to many more bugs. Writing a GUI app well is hard. Writing a toolkit to run that GUI app is hard. Writing all the other libraries and services to support a full-featured desktop, based on those GUI apps and toolkits is hard * hard. X, while providing a non-specific platform for windowing, has not provided any indication as to how those windows should look or behave. That means every app running in X relies on a MOUNTAIN of libraries. One critical bug in one of those library (which are developed by groups all over the world that all have their own way of doing things and their own plans) means the app has a critical bug. Multiply that by all the leaky abstractions inherent in layers upon layers of libraries, and you've got a big, fat mess.
This isn't to say X apps couldn't be great. With well-defined, well-documented, and well-standardized development practices, interfaces, and protocols, the leaks between layers would certainly be lessened. Right now, however, I run apps under X holding my breath. I've had critical applications crash far too often (usually losing work in the progress) to trust them anymore.
And you know what? vi doesn't crash. Why? Because it's not piled upon a hundred layers of libraries that all have their own problems. Writing GUI desktop applications is hard. Writing them under X is monumentally hard.