Half my extensions are busted. TargetAlert, Flashblock, SessionSaver... those are the three most important disabled ones right now. Fortunately, it appears I no longer need SlashFix or Tab Mix (try dragging the tabs around).
SessionSaver ".2d1 nightly 30" works on the recent Firefox betas/nightlies. I believe this is the new home page.
(This extension's history is a study in chaotic development; several forks with the same name, appended version numbers, different authors, patches, posted across a bunch of web forums containing hundreds of complaints and comments. You have to wonder why they didn't just create a wiki page somewhere, or at least a web page on some free hosting service, and tie the damn threads together.)
You may want to check out Tsync, one of the recent Google "Summer of Code" winners: "Tsync is a user-level daemon that provides transparent synchronization amongst a set of computers. Tsync uses a peer-to-peer architecture for scalability, efficiency, and robustness." Unlike rsync, Unison, etc., Tsync is a locally installed daemon which automatically and transparently syncs two or more hosts.
The FreeBSD Java home page says: "The current release of the JDK and JRE available via the FreeBSD Foundation is 1.3.1". As for 1.4.x, use "in a production environment is at your own risk", according to the porting team. The Java 5 port is, as you say, alpha quality.
Easy there, fanboy. The article was about Netbeans, not Eclipse.
The article may have been about Netbeans, but it was very much a comparison of Netbeans against Eclipse; Eclipse is mentioned twice in the Slashdot story.
You actually completely missed the intent of my comment, and in the same turn managed to embody the exact same defensive attitude I was describing. As Eclipse has grown in popularity, so has the poison spewed by Netbeaners; the Eclipse community, in fact, has been rather surprised and annoyed by the aggression. Calling somebody a "fanboy" is not exactly a step on the road to civilized discussion. Please do realize that I myself have not attacked Netbeans in any way: I merely explained Eclipse's position in relation to Sun's stuff.
As I was saying, Eclipse filled a demand that Sun/Swing/Netbeans could not satisfy: you may not accept it, but one of the major reasons Eclipse is so popular is precisely for the reasons I emphasized.
I'm not interested in converting anyone, and I'm quite happy letting you use your GUI emulation software and your IDE. But for me, and for countless other users and developers, Eclipse represents a different philosophy that makes more sense.
All I have to say is that I percieve SWT to break the core reason for Java in the first place--write once, run anywhere.
Anyone who has done any serious amount of work with Java knows that the "write once, run anywhere" mantra is an illusion.
Personally, I prefer the route taken by Ruby, Python etc.: provide solid standard libraries and abstractions of OS mechanisms, but generally let the user do whatever he likes. It's wonderfully easy to write cross-platform tools in Ruby, and you're not locked into a cage where you can't access OS primitives that the VM authors didn't think about including. (Unix domain sockets, real file locking and process control are some examples.)
It's also curious what this "anywhere" really means. Last I checked, FreeBSD still did not have a stable version of Java 1.4, let alone Java 5.0; compared to a platform such as Ruby or Python, Java's platform-portability is rather pitiful, and Sun's restrictive licensing does not help one bit.
Try running your favorite SWT app (including Eclipse) on a Mac. Java was supposed to alleviate platform differences.
I have no problems admitting that the current SWT implementation is flawed on OS X; but that's a problem with the implementation, not the concept. There's every reason why SWT can succeed on the Mac.
As an example, you mention ClearType. ClearType is a platform-specific technology...
Sub-pixel rendering is related to monitor hardware, not platforms. I used the term ClearType in the general sense, not as in the Microsoft-trademarked stuff.
... and although it looks pretty on SWT apps in Windows, running that same app on other platforms produces no benefit.
This is patently wrong. Other platforms that implement sub-pixel rendering will benefit because Eclipse uses their font rendering systems. On the Mac, Eclipse uses Carbon and thus gets sub-pixel rendering for free, just as on Windows. On Linux, Eclipse uses GTK+, which I believe also implements sub-pixel rendering at the toolkit level. Similarly, if GTK+ itself is upgraded with new features or optimizations, Eclipse apps immediately benefit; Swing apps do not.
Granted, sub-pixel rendering is a nice feature, but why not implement it at the LaF level, and not at the native peer-esque SWT level...
Precisely because it's in the province of the GUI subsystem. An application should not need to implement a whole GUI subsystem.
For example, Eclipse apps can use TrueType and (if you have Adobe Type Manager installed) Type 1 fonts. Eclipse apps can use the native printing subsy
As with any competing products, there is a certain amount of contention between adherents of Netbeans and Eclipse users alike; much vitriol has been spilled recently, mostly by aggressive Sun employees and Netbeans developers who seem overly defensive about their favourite product's worth -- they have seen Eclipse steamroll and, ahem, eclipse their own IDE effort and gather all the momentum and attention that the Netbeans project never could.
It's too easy to blame IBM and its financial support. Clearly, there is a huge demand for an extensible, vendor-neutral IDE platform, a demand Eclipse immediately satisfied. There is also a huge demand for native widgets that Sun seems to have ignored or overlooked; the world is thirsting for good, cross-platform GUI toolkits, and for many people and companies, Swing has never been a real option. Sun has never seen the beam in their own eye that is Swing. Java GUI apps have never really taken off because of the real and perceived weaknesses of Swing, but with SWT and Eclipse we're seeing renewed interest in Java as a language for "real" GUI apps.
I'm in the SWT camp myself. I prefer to deal with native widgets in the IDE -- and Eclipse performs and looks very well on Windows (with non-Windows platform support catching up) -- and as an end user, Swing apps have always peeved me; for example, when I got an LCD monitor, no Swing apps could exploit ClearType, which all Windows apps -- Eclipse included -- do automatically by virtue of using a single font renderer. When you emulate something that is constantly evolving, you will always get an imperfect emulation; not to mention that satisfactory emulation of a whole OS -- because GUIs is more than just look and feel -- is nigh impossible; note, for example, how Windows XP themes don't work on Swing apps.
I also love the fact that I can develop native applications with Eclipse's RCP (Rich Client Platform) framework, and I can do it with ease unparallelled since the days of Borland Delphi.
Netbeans probably has an edge when it comes to J2EE support at the moment. Developing framework-specific tools -- J2EE, XML, etc. -- has always been secondary to delivering Eclipse proper. Eclipse has many rapidly-evolving subprojects covering plugins for J2EE, web standards, aspect-oriented programming, graphical modeling, performance/quality testing and so on.
While not all ready for production, the quality of these tools is often amazing; as significantly, a lot of thought is always put into making tools extensible and based on reusable frameworks. For example, the graphical modeling plugin is based on a generic graph-editing framework (the GEF) which can be reused in your own applications. Eclipse itself I find to be a momentous and beautiful engineering effort, based on solid, pragmatic OO design.
To check in a file, I have to pop up the package explorer, find the file, right-click, select Team->Commit...
Nah. Just right-click in the text editor view and select Team -> Commit from the context menu.
(This is Eclipse 3.1M6; I don't remember how long this feature has existed. Same disclaimer goes for the items below.)
And have you looked at the Team Synchronizing perspective? In this perspective you get a project-level diff between the working version and the repository; it will show outgoing and incoming modifications as well as conflicts, and it's a wonderful way to commit or update. It also supports commit sets, which let you set up the changeset without accessing the server, and then, when you're done, commit it as a whole.
CVS updates require way too many mouse clicks. It always asks me if I want to update from a different tag (this is rarel, if ever, done; the update command should just update the current tag without an intermediate dialog).
Team -> Update will never ask for a tag; it defaults to the branch you're working on.
Once the update command finishes, the output is simply discarded, making it harder to see what files were patched, modified, conflict, etc.
The CVS console shows this information, and the output is almost identical to that of the official CVS client. Window -> Show View -> Console, then make sure it's showing the CVS console by selecting this from the dropdown inside the view (as there are other types of consoles).
other version control system (RCS, subversion, etc.)
While Eclipse only has CVS integration out of the box, there are third-party plugins providing support for Subversion, Perforce, ClearCase, an experimental system called Stellation, and others.
As for RCS, keep in mind that Eclipse has a powerful, and very useful, local history function that transparently maintains older versions of your source files. You can define the maximum age of this history. No commit messages or tagging, however.
Apparently, person who reverse-engineers is now called a "reverse engineer":
According to attendees, Tridgell demonstrated the procedure to disprove accusations that his detractors in the Torvalds/McVoy camp had made against him. Principally, that he was some kind of "an evil genius" reverse engineer.
From an operational standpoint -- meaning, roughly, that the output is actually something you want to run, only the following toolkits have responsive, shell-integrating output: [...]
This is a question: The screenshots, though fuzzy from compression and scaling, show a nice-looking, minimalistic theme with a really clean font -- not, I'm pretty sure, the default GNOME font. Can anyone here identify this theme and font?
Interesting to note that Windows XP can do what you describe NetDrive doing - mount a webDAV remote location as a drive or network resource/web folder, allowing straight drag and drop capability.
Windows XP doesn't "mount" anything. It works like Konqueror's plugins. The WebDAV access is a shell feature (implemented in IE/Explorer), not an OS feature.
The downside to this approach is that the mount doesn't work like the file system; for example, you can't open a remote file in Notepad, edit it and save. You have to drag it locally, edit it, then drag it back.
OS X does it the right way -- it provides a file-system driver, letting you mount remote WebDAV folders into your file system, using mount (or mount_webdav directly) on the command line, or the Finder GUI. A remote file can be edited like any other file.
On Windows you will need to install a product such as WebDrive. WebDrive mounts WebDAV and FTP sites as drive letters.
I was so early to Delphi that Borland Australia's sales staff hadn't even heard of it the first time I called up to order a copy. It was only available on CD-ROM, so I had to borrow a friend's CD drive long enough to install it.
Same here. A friend of mine got one of the first units of Delphi 1.0 to reach Norway, and I immediately went over and got a copy -- on floppy disks, as I recall. That was a grand day.
It's funny how one of the milestones in computer programming was missed by most developers, mainly because of bad marketing and development decisions. (Sure, it was a Windows app, but at the time, Windows' only serious GUI competitor was MacOS -- GNOME and KDE didn't even exist.)
Borland couldn't market raw meat to wolves. They lack even the microscopicest smidgen of clue. They're idiots, through and through. Such a shame a magnificent programming tool like Delphi had to die because of a bunch of wankers in suits.
Right on. The worst part of it is that they're still doing it wrong.
Ahead of its time, etc.
on
Delphi Turns 10
·
· Score: 5, Insightful
I don't expect too many Slashdotters know about Delphi because of its Windows origins. Delphi comprises:
A Java-like OO dialect of Pascal.
A native compiler for this language.
An elegant Qt-like component toolkit, comprising both UI widgets and non-visual components such as databases.
An elegant set of GUI design tools for this toolkit.
An IDE with an integrated interactive debugger.
The combination lets developers whip up full-featured GUI apps in minutes. This concept was hyped as "RAD" -- rapid application development: Create a new form. Put a tabular editor widget on it. Put a data source component on it. Hook the table widget visually to the data source. Now you have a table containing your database's data.
Delphi later wooed COM/DCOM and CORBA, and added these two systems as first-class citizens in the language, similar to RMI or Distributed Ruby -- suddenly it was a snap to write an app whose objects lived in a separate process or on a remote machine. It was part of an ill-fated strategy to capture the "middleware" market.
Borland's Java product, JBuilder, tried to be "Delphi for Java", but failed to live up to the "just works"-quality of its parent product. Even later, Delphi has gone after.NET, but I stopped paying attention long before that.
Delphi could have been big. It was a masterpiece in engineering. Sadly, Borland shot themselves in the foot in several ways:
They treated their users like crap.
They focused on the wrong technologies, not the stuff that made Delphi good.
They were incredibly slow in going after open source.
They handled the open source move badly. When they finally released the InterBase source, they almost immediately changed their minds and went back to making it proprietary again. The open-source version, Firebird, survives, but is no longer aided by Borland in the way that was originaly planned.
They let their star visionary/engineer, Anders Hejlsberg, be stolen away by Microsoft along with a handful of other core employees.
They annihilated their once-great quality assurance. Delphi 3 and 4 were beta-quality software.
They had a brilliant C++ version of Delphi, but it was treated as the idiot inbred cousin, lagging behind in features and being saddled with yet another crummy proprietary, incompatible dialect of C++.
They spent a lot of effort on Linux, with the Kylix product, which to my knowledge has never taken off.
They did not evolve the language. For example, it was hard to interface with C APIs. (I wrote a rather successful C/C++ translator called htrans that helped me write the wrappers needed to interface with tech such as TAPI, MAPI and various other COM libs; it was the only way.)
Part of Borland's fall from grace may be blamed on greed -- greed and the dot-com era. They were originally a development tools company. But even after the Philippe Kahn-era attempt to compete with Microsoft (Quattro Pro, etc.) failed, the execs made a similar mistake by going after the gold mine that is the enterprise consultancy business.
They renamed their company Inprise, touted a bunch of half-assed products, and drowned their web site and communication in buzzwords about enterprise middleware, B2B, application servers and other stuff that were the obvious product of executives, not visionary engineers. They were not just a product company any more, but now also a "solutions" company. And rather than going after common-sense technologies, they went where the hype was. Their new products were also not up to the quality that customers knew and loved from previous products. In the end, they had the arrogance suited for the business, but not the savvy. So they failed.
Borland have refocused in recent years, and the effort is commendable, but they have not regained their former reputation. For one, I don't know anyone who uses Delphi anymore.
Darcs, a simple, human-friendly, completely distributed version control system. Does away with dedicated servers (even your desktop can be a "server"), branches (every repository is a branch) and CVS warts (tracks renames, deletes, directories).
I can do real-time encoding (single-pass) of DVDs into libavcodec/MPEG4, and 2-passes with only 50% more time, on my 1.66GHz CPU. I can do 2-pass MPEG-2 encoding in realtime.
Real-time is not fast enough.
Sounds like you should use VNC or X11 over the network, or perhaps some other front-end which works with the data locally.
As the article points out, the user no longer has to wait for the word processor to catch up to their typing. So what are users waiting for these days?
As for myself, I can tell you:
Browsing/rendering of web pages. I'm on a 10mbps broadband connection in Norway, and pages in the US still take an awful long time to download and render. European sites are usually much zippier.
Java GUI apps; specifically, Eclipse. Eclipse is actually pretty fast, although it's hampered by Windows' eager trim-process-working-set-on-minimize algorithm, which means that whenever you de-minimize the app after having had it minimized for a while, it will take up to a minute to un-swap.
Until a few weeks ago, Thunderbird. This is also hit by the above-mentioned swapping bug (which you can solve by placing the following in your user.js file:
user_pref("config.trim_on_minimize", false);). Actually, Thunderbird is pretty slow overall.
LAN file transfer/browsing with Samba. 100mbps networks just aren't that fast anymore. Time to go 1000mbps.
Burning CDs/DVDs. Even with my 40X/4X burner it's a pain. The transfers are fast, but what the vendors never tell you is that the speed metric on the package doesn't include the huge overhead in starting and finalizing the burning.
Compiling stuff, of course.
Encoding movies, eg. DVD -> XviD backups for personal use. Where's a distributed cross-platform XviD encoder when you need one?
Tagging MP3 files with IDv2 over the LAN. Audio files badly need a metadata format that doesn't require rewriting the whole file.
Computers really aren't that slow anymore. I used to stay on the bleeding edge in performance, and ever since the first Pentium III and Celerons arrived I have been happy running stuff that isn't the latest generation.
The key is running with enough RAM and a reasonably fast hard drive. Programs consume a lot more RAM these days (and operating systems subsequently spend more cycles managing it), and hard drives are still horribly slow relative to everything else.
That said, until recently I owned a PowerBook G4 1GHz/512MB, and on that box I usually had to wait for anything. Apple did a great job on the user interface, but there's a ~50ms latency pervading the entire GUI, and whoever implemented Finder and the SMB file browser deserves to be hacked to death by flocks of rabid zombie pigeons.
Note that this isn't a particular vulnerability, just a system of typing that makes it easy to introduce vulnerabilities, which last time I checked, all C programmers deal with.
Yes, CowboyNeal, but do they want to deal with it, and should they deal with it?
For every programmer who reads security bulletins and keeps tabs on the latest string-copying buffer overflow issues and fundamental security principles, there are a hundred who don't know or care.
C is a high-level language that:
Has direct access to every part of the operating system and executes instructions directly from memory. This means that malicious code can slip into its memory space through buffer overflow exploitations and the like.
Is, in almost all cases/operating systems, running with the same capabilities as the logged-in user, which means it has virtually endless power that ranges from formatting your hard drive to infecting other nodes with worms or looking through your email app's address book. It's not limited to the desktop computer of the hapless Windows user, either: Unix daemons running on servers as non-root users can cause serious havoc.
Programmers want to be productive -- most want to make things make colourful stuff happen on the screen, not fiddle around with buffer guard code. So the more security can be built into the language and its running environment, the better.
Many languages, such as Python or Ruby, provide security against what I mention in my first bullet, through a virtual machine. They're not impenetrable, and are of course, as dynamic languages, subject to a different class of security holes (eg., string evaluation of code), but they're a step up from the C level.
Other languages, like Java, provide capability-based security models, allowing for sandbox environments with fine-grained control over what a program may or may not do. Java's security system is ambitious, but since most Java apps run on the server these days, it's not frequently used, and except for browser applets, Java code tend to run unchecked.
In a way, Java tries to do what the OS should be doing. Programs run on behalf of its human user, and their destructive power is scary. Why should any given program running on my PC have full access to my documents or personal data?
As we're entering an age where we have more and smaller programs, and the difference between "my PC" and "the net" is increasingly blurred.
Operating systems need to evolve into being able to distinguish between different capabilities it can grant to programs, or processes -- we need to think about our programs as servants that are doing work for us by proxy.
The same way you wouldn't let a personal servant manage your credit cards, you don't want to let your program do it -- unless, of course, it was a servant (or, following this metaphor, program) hired to deal with credit cards, which introduces the idea of trust. The personal accountant trusts the bank clerk, who trusts the people handling the vault, who trust the people who built the vault, and so on.
In short, any modern computer system needs to support the notions of delegated powers, and trust.
Programmers will certainly never stop having to consider vulnerabilities in code. But painstakingly working around pitfalls inherent in one's language, be it C or indeed.NET -- we need to evolve past that. The users, upon whom we exert so much power, certainly deserve it.
Maybe you've heard about Ruby on Rails, the super productive new way to develop web applications, and you'd like to give it a try, but you don't know anything about Ruby or Rails. This article steps through the development of a web application using Rails. It won't teach you how to program in Ruby, but if you already know another object-oriented programming language, you should have no problem following along (and at the end you can find links on learning Ruby).
As a result, you will become a happier, more spiritually enlightened person. No, really!
The whole Ruby-on-Rails framework seems predicated on the idea that the application (and hence everyone on the internet) has unfettered access to the database.
Rails does not assume this. Rails only does what you let it; if you write data-reading code, the connection must have read access to the DB, and if your code updates the data, the connection must have write access.
You how structure and delegate this access is up to you.
The phrase "stored procedure" doesn't even seem to be in the R-o-R developers' vocabulary. This causes me to immediately discard it as a tool for serious work.
Rails does not rely on stored procedures because the SP is not a relational construct -- it's an imperative language construct. Rails relies on relations, and it relies on introspection features in the database to automagically map tables to classes and rows to objects.
You can certainly invoke stored procs from Rails. While Rails abstracts data access, you still have direct access to the database if you need it. But this means bypassing the nice object-relational mapping sugar that makes Rails such a productive framework in the first place.
You could certainly extend Rails's mapper (which is called ActiveRecord) to let users specify the extra metadata needed to map stored procedure calls to objects.
And lastly, ActiveRecord is not required to use Rails. You could replace it with something equally simple; ActiveRecord is just 5,000 lines of Ruby code plus another 3,500 for the database adapters.
It looks like a nice toy, and perhaps even a useful one, but it's still a toy.
I'm going to counter your arrogant, childishly intolerant trolling with a sensible counter-argument. It's a difference in philosophy -- monolithic database apps vs. distributed ones.
Some developers like to keep the database pure -- let the database worry about the data and provide a few basic operators to access and manipulate the data. Then on top of that you layer whatever data-management engine you want. These developers consider stored procedures a bit dirty because it couples the logic more tightly to the data, and introduces portability problems.
Of course, stored procedures have benefits, too, such as centralizing the core logic so that it can be accessed through the database CLI from any component in any language. That kind of model is powerful and useful, but is growing weaker as databases become increasingly loosely coupled.
I'm looking for a 19" widescreen LCD that runs at least 1600 pixels wide, and naturally below 20ms, in the $500-600 range.
Something tells me this does not exist. All the 19" monitors I see are 1280x1024. That's a ridiculous resolution for such a huge display -- even my 15" PowerBook's 1280x854 resolution is silly and feels cramped.
There are 20" monitors running at 1600, but the corresponding jump in price (eg., an Eizo L887) means they are out of my league.
If I were in charge, I would be a little less coy about the.dfm file and its textual representation. I may also consider a standardized Pascal syntax for describing graphs and data -- there is this thing called VHDL that has an IEEE standard and is used for hardware design, but it seems perfectly suited for a Pascal-syntax answer to XML. And for you C-syntax proponents, there is this thing called Verilog.
Slashdot Mirror
SessionSaver ".2d1 nightly 30" works on the recent Firefox betas/nightlies. I believe this is the new home page.
(This extension's history is a study in chaotic development; several forks with the same name, appended version numbers, different authors, patches, posted across a bunch of web forums containing hundreds of complaints and comments. You have to wonder why they didn't just create a wiki page somewhere, or at least a web page on some free hosting service, and tie the damn threads together.)
You may want to check out Tsync, one of the recent Google "Summer of Code" winners: "Tsync is a user-level daemon that provides transparent synchronization amongst a set of computers. Tsync uses a peer-to-peer architecture for scalability, efficiency, and robustness." Unlike rsync, Unison, etc., Tsync is a locally installed daemon which automatically and transparently syncs two or more hosts.
Plone does exactly this -- it's one of its main features. Plone probably has the best interionalization/localization support of any current CMS.
http://www.google.com/talk/
Link is down, so here are more news articles, courtesy of Google News.
- Solaris 10 and Open Solaris (which you build and install on Solaris Express) are both very nice, Linux-like operating systems.
Linux is no longer "Unix-like", people. It's Unix that is "Linux-like".The FreeBSD Java home page says: "The current release of the JDK and JRE available via the FreeBSD Foundation is 1.3.1". As for 1.4.x, use "in a production environment is at your own risk", according to the porting team. The Java 5 port is, as you say, alpha quality.
The article may have been about Netbeans, but it was very much a comparison of Netbeans against Eclipse; Eclipse is mentioned twice in the Slashdot story.
You actually completely missed the intent of my comment, and in the same turn managed to embody the exact same defensive attitude I was describing. As Eclipse has grown in popularity, so has the poison spewed by Netbeaners; the Eclipse community, in fact, has been rather surprised and annoyed by the aggression. Calling somebody a "fanboy" is not exactly a step on the road to civilized discussion. Please do realize that I myself have not attacked Netbeans in any way: I merely explained Eclipse's position in relation to Sun's stuff.
As I was saying, Eclipse filled a demand that Sun/Swing/Netbeans could not satisfy: you may not accept it, but one of the major reasons Eclipse is so popular is precisely for the reasons I emphasized.
I'm not interested in converting anyone, and I'm quite happy letting you use your GUI emulation software and your IDE. But for me, and for countless other users and developers, Eclipse represents a different philosophy that makes more sense.
Anyone who has done any serious amount of work with Java knows that the "write once, run anywhere" mantra is an illusion.
Personally, I prefer the route taken by Ruby, Python etc.: provide solid standard libraries and abstractions of OS mechanisms, but generally let the user do whatever he likes. It's wonderfully easy to write cross-platform tools in Ruby, and you're not locked into a cage where you can't access OS primitives that the VM authors didn't think about including. (Unix domain sockets, real file locking and process control are some examples.)
It's also curious what this "anywhere" really means. Last I checked, FreeBSD still did not have a stable version of Java 1.4, let alone Java 5.0; compared to a platform such as Ruby or Python, Java's platform-portability is rather pitiful, and Sun's restrictive licensing does not help one bit.
I have no problems admitting that the current SWT implementation is flawed on OS X; but that's a problem with the implementation, not the concept. There's every reason why SWT can succeed on the Mac.
Sub-pixel rendering is related to monitor hardware, not platforms. I used the term ClearType in the general sense, not as in the Microsoft-trademarked stuff.
This is patently wrong. Other platforms that implement sub-pixel rendering will benefit because Eclipse uses their font rendering systems. On the Mac, Eclipse uses Carbon and thus gets sub-pixel rendering for free, just as on Windows. On Linux, Eclipse uses GTK+, which I believe also implements sub-pixel rendering at the toolkit level. Similarly, if GTK+ itself is upgraded with new features or optimizations, Eclipse apps immediately benefit; Swing apps do not.
Precisely because it's in the province of the GUI subsystem. An application should not need to implement a whole GUI subsystem.
For example, Eclipse apps can use TrueType and (if you have Adobe Type Manager installed) Type 1 fonts. Eclipse apps can use the native printing subsy
It's too easy to blame IBM and its financial support. Clearly, there is a huge demand for an extensible, vendor-neutral IDE platform, a demand Eclipse immediately satisfied. There is also a huge demand for native widgets that Sun seems to have ignored or overlooked; the world is thirsting for good, cross-platform GUI toolkits, and for many people and companies, Swing has never been a real option. Sun has never seen the beam in their own eye that is Swing. Java GUI apps have never really taken off because of the real and perceived weaknesses of Swing, but with SWT and Eclipse we're seeing renewed interest in Java as a language for "real" GUI apps.
I'm in the SWT camp myself. I prefer to deal with native widgets in the IDE -- and Eclipse performs and looks very well on Windows (with non-Windows platform support catching up) -- and as an end user, Swing apps have always peeved me; for example, when I got an LCD monitor, no Swing apps could exploit ClearType, which all Windows apps -- Eclipse included -- do automatically by virtue of using a single font renderer. When you emulate something that is constantly evolving, you will always get an imperfect emulation; not to mention that satisfactory emulation of a whole OS -- because GUIs is more than just look and feel -- is nigh impossible; note, for example, how Windows XP themes don't work on Swing apps.
I also love the fact that I can develop native applications with Eclipse's RCP (Rich Client Platform) framework, and I can do it with ease unparallelled since the days of Borland Delphi.
Netbeans probably has an edge when it comes to J2EE support at the moment. Developing framework-specific tools -- J2EE, XML, etc. -- has always been secondary to delivering Eclipse proper. Eclipse has many rapidly-evolving subprojects covering plugins for J2EE, web standards, aspect-oriented programming, graphical modeling, performance/quality testing and so on.
While not all ready for production, the quality of these tools is often amazing; as significantly, a lot of thought is always put into making tools extensible and based on reusable frameworks. For example, the graphical modeling plugin is based on a generic graph-editing framework (the GEF) which can be reused in your own applications. Eclipse itself I find to be a momentous and beautiful engineering effort, based on solid, pragmatic OO design.
Nah. Just right-click in the text editor view and select Team -> Commit from the context menu.
(This is Eclipse 3.1M6; I don't remember how long this feature has existed. Same disclaimer goes for the items below.)
And have you looked at the Team Synchronizing perspective? In this perspective you get a project-level diff between the working version and the repository; it will show outgoing and incoming modifications as well as conflicts, and it's a wonderful way to commit or update. It also supports commit sets, which let you set up the changeset without accessing the server, and then, when you're done, commit it as a whole.
Team -> Update will never ask for a tag; it defaults to the branch you're working on.
The CVS console shows this information, and the output is almost identical to that of the official CVS client. Window -> Show View -> Console, then make sure it's showing the CVS console by selecting this from the dropdown inside the view (as there are other types of consoles).
While Eclipse only has CVS integration out of the box, there are third-party plugins providing support for Subversion, Perforce, ClearCase, an experimental system called Stellation, and others.
As for RCS, keep in mind that Eclipse has a powerful, and very useful, local history function that transparently maintains older versions of your source files. You can define the maximum age of this history. No commit messages or tagging, however.
Not so sure about that. But then it could just be the anti-aliasing and fuzziness of the images.
You forgot SWT.
This is a question: The screenshots, though fuzzy from compression and scaling, show a nice-looking, minimalistic theme with a really clean font -- not, I'm pretty sure, the default GNOME font. Can anyone here identify this theme and font?
Windows XP doesn't "mount" anything. It works like Konqueror's plugins. The WebDAV access is a shell feature (implemented in IE/Explorer), not an OS feature.
The downside to this approach is that the mount doesn't work like the file system; for example, you can't open a remote file in Notepad, edit it and save. You have to drag it locally, edit it, then drag it back.
OS X does it the right way -- it provides a file-system driver, letting you mount remote WebDAV folders into your file system, using mount (or mount_webdav directly) on the command line, or the Finder GUI. A remote file can be edited like any other file.
On Windows you will need to install a product such as WebDrive. WebDrive mounts WebDAV and FTP sites as drive letters.
Same here. A friend of mine got one of the first units of Delphi 1.0 to reach Norway, and I immediately went over and got a copy -- on floppy disks, as I recall. That was a grand day.
It's funny how one of the milestones in computer programming was missed by most developers, mainly because of bad marketing and development decisions. (Sure, it was a Windows app, but at the time, Windows' only serious GUI competitor was MacOS -- GNOME and KDE didn't even exist.)
Right on. The worst part of it is that they're still doing it wrong.
The combination lets developers whip up full-featured GUI apps in minutes. This concept was hyped as "RAD" -- rapid application development: Create a new form. Put a tabular editor widget on it. Put a data source component on it. Hook the table widget visually to the data source. Now you have a table containing your database's data.
Delphi later wooed COM/DCOM and CORBA, and added these two systems as first-class citizens in the language, similar to RMI or Distributed Ruby -- suddenly it was a snap to write an app whose objects lived in a separate process or on a remote machine. It was part of an ill-fated strategy to capture the "middleware" market.
Borland's Java product, JBuilder, tried to be "Delphi for Java", but failed to live up to the "just works"-quality of its parent product. Even later, Delphi has gone after .NET, but I stopped paying attention long before that.
Delphi could have been big. It was a masterpiece in engineering. Sadly, Borland shot themselves in the foot in several ways:
Part of Borland's fall from grace may be blamed on greed -- greed and the dot-com era. They were originally a development tools company. But even after the Philippe Kahn-era attempt to compete with Microsoft (Quattro Pro, etc.) failed, the execs made a similar mistake by going after the gold mine that is the enterprise consultancy business.
They renamed their company Inprise, touted a bunch of half-assed products, and drowned their web site and communication in buzzwords about enterprise middleware, B2B, application servers and other stuff that were the obvious product of executives, not visionary engineers. They were not just a product company any more, but now also a "solutions" company. And rather than going after common-sense technologies, they went where the hype was. Their new products were also not up to the quality that customers knew and loved from previous products. In the end, they had the arrogance suited for the business, but not the savvy. So they failed.
Borland have refocused in recent years, and the effort is commendable, but they have not regained their former reputation. For one, I don't know anyone who uses Delphi anymore.
Perhaps most sign
Darcs, a simple, human-friendly, completely distributed version control system. Does away with dedicated servers (even your desktop can be a "server"), branches (every repository is a branch) and CVS warts (tracks renames, deletes, directories).
Real-time is not fast enough.
Tag&Rename doesn't exist on Linux.
As for myself, I can tell you:
Computers really aren't that slow anymore. I used to stay on the bleeding edge in performance, and ever since the first Pentium III and Celerons arrived I have been happy running stuff that isn't the latest generation.
The key is running with enough RAM and a reasonably fast hard drive. Programs consume a lot more RAM these days (and operating systems subsequently spend more cycles managing it), and hard drives are still horribly slow relative to everything else.
That said, until recently I owned a PowerBook G4 1GHz/512MB, and on that box I usually had to wait for anything. Apple did a great job on the user interface, but there's a ~50ms latency pervading the entire GUI, and whoever implemented Finder and the SMB file browser deserves to be hacked to death by flocks of rabid zombie pigeons.
Yes, CowboyNeal, but do they want to deal with it, and should they deal with it?
For every programmer who reads security bulletins and keeps tabs on the latest string-copying buffer overflow issues and fundamental security principles, there are a hundred who don't know or care.
C is a high-level language that:
Programmers want to be productive -- most want to make things make colourful stuff happen on the screen, not fiddle around with buffer guard code. So the more security can be built into the language and its running environment, the better.
Many languages, such as Python or Ruby, provide security against what I mention in my first bullet, through a virtual machine. They're not impenetrable, and are of course, as dynamic languages, subject to a different class of security holes (eg., string evaluation of code), but they're a step up from the C level.
Other languages, like Java, provide capability-based security models, allowing for sandbox environments with fine-grained control over what a program may or may not do. Java's security system is ambitious, but since most Java apps run on the server these days, it's not frequently used, and except for browser applets, Java code tend to run unchecked.
In a way, Java tries to do what the OS should be doing. Programs run on behalf of its human user, and their destructive power is scary. Why should any given program running on my PC have full access to my documents or personal data? As we're entering an age where we have more and smaller programs, and the difference between "my PC" and "the net" is increasingly blurred. Operating systems need to evolve into being able to distinguish between different capabilities it can grant to programs, or processes -- we need to think about our programs as servants that are doing work for us by proxy.
The same way you wouldn't let a personal servant manage your credit cards, you don't want to let your program do it -- unless, of course, it was a servant (or, following this metaphor, program) hired to deal with credit cards, which introduces the idea of trust. The personal accountant trusts the bank clerk, who trusts the people handling the vault, who trust the people who built the vault, and so on.
In short, any modern computer system needs to support the notions of delegated powers, and trust.
Programmers will certainly never stop having to consider vulnerabilities in code. But painstakingly working around pitfalls inherent in one's language, be it C or indeed .NET -- we need to evolve past that. The users, upon whom we exert so much power, certainly deserve it.
As a result, you will become a happier, more spiritually enlightened person. No, really!
Rails does not assume this. Rails only does what you let it; if you write data-reading code, the connection must have read access to the DB, and if your code updates the data, the connection must have write access.
You how structure and delegate this access is up to you.
Rails does not rely on stored procedures because the SP is not a relational construct -- it's an imperative language construct. Rails relies on relations, and it relies on introspection features in the database to automagically map tables to classes and rows to objects.
You can certainly invoke stored procs from Rails. While Rails abstracts data access, you still have direct access to the database if you need it. But this means bypassing the nice object-relational mapping sugar that makes Rails such a productive framework in the first place.
You could certainly extend Rails's mapper (which is called ActiveRecord) to let users specify the extra metadata needed to map stored procedure calls to objects.
And lastly, ActiveRecord is not required to use Rails. You could replace it with something equally simple; ActiveRecord is just 5,000 lines of Ruby code plus another 3,500 for the database adapters.
I'm going to counter your arrogant, childishly intolerant trolling with a sensible counter-argument. It's a difference in philosophy -- monolithic database apps vs. distributed ones.
Some developers like to keep the database pure -- let the database worry about the data and provide a few basic operators to access and manipulate the data. Then on top of that you layer whatever data-management engine you want. These developers consider stored procedures a bit dirty because it couples the logic more tightly to the data, and introduces portability problems.
Of course, stored procedures have benefits, too, such as centralizing the core logic so that it can be accessed through the database CLI from any component in any language. That kind of model is powerful and useful, but is growing weaker as databases become increasingly loosely coupled.
Something tells me this does not exist. All the 19" monitors I see are 1280x1024. That's a ridiculous resolution for such a huge display -- even my 15" PowerBook's 1280x854 resolution is silly and feels cramped.
There are 20" monitors running at 1600, but the corresponding jump in price (eg., an Eizo L887) means they are out of my league.
And there is YAML. It's already quite popular.