Java is the COBOL of our generation.
on
Java Is So 90s
·
· Score: 1
I have to agree with the OP. We'll be living with big bloated Java systems well into the afterlife, just like we're living with the big bloated COBOL systems of yesteryears. Why? They're the same sort of systems.
Big 'enterprise' in-house systems which keep the business running. The COBOL ones which got re-written in the later 90s got rewritten to what -- Java. And they're not going to do that again for a good long time.
So, we've traded COBOL/VSAM for Java/EJB (shudder) or JDBC. Traded the expensive as hell VM system for an expensive as hell J2EE container. Or maybe JBoss.
And the folks getting rich doing the maintenance in 15 years will be the 'old timers' which still know Java / J2EE . And I pity them and their deployment descriptors.
I remember attending a presentation from Sun personel demoing their portal mail system, how they prided themselves at not competing with the application providers who develop for Solaris. I remember Oracle was mentioned specifically by name. They provided a counter-example in Microsoft, who produces both SQL-Server and the operating system.
Oh well.
So confused -- Sun becomes more evil by supporting PostgreSQL ?
Which they released a 'legal', but value-added-only-for-microsoft extension, whose documentation was explicitly licensed as to prevent you from making an open-source interoperable equivalent.
AFAIR, anyway. Does SambaNG or whatever truly smell like an AD with the MS-KRB5 authorization field properly filled-in?
But now that Apple is using the same processor as everyone else, targeting the Macs will now be an easy decision to make. This will be at the expense of Linux.
Yeah, all of that inline assembler code will now 'just work'. X11 versus Cocoa has absolutely _nothing_ to do with porting efforts, does it?
Our webshop develops on OSX (save one die-hard linux laptop uber-coder), then deploys production on SuSE/x86.
Best of both worlds. Now, this could slow down KDE / Gnome development (why bother 'suffering' under X11 anymore?), but at the same time it might well _aid_ the GNUStep project as folks want to get their newfound Cocoa apps running under Linux. Even with Webcore. </ObHandWaving>
Under OSX, I unpack the DMG on a test box, and if all looks good, I tar it up and cron out the update to all of our desktop boxes. The cron script tests the installed version's version string inside the plist file against the expected one, and, if not the same, then fetches the tarball from webspace and unpacks.
Social contract aside, AdBlock plugins and friends, if they become truly popular, will just cause the advertizements to become more and more inlined and camoflaged within the content of the site.
And so the arms race will up one notch, with the next generation of adblockers knowing how to filter those out too. Virus versus antivirus. Spam versus filters. Predator versus prey (but which is which exactly?).
I somewhat believe that a new flavor of turing test oughta be 100% spamblock capability with no false positives. Or automatic DVR commercial skipping. Or webpage adblocking. If it filters as well as I could these days, then slap an 'intelligent' badge on it and move on.
(3) by inserting after paragraph (10) the following:
(11) the making imperceptible, by or at the direction of a member of a private household, of limited portions of audio or video content of a motion picture, during a performance in or transmitted to that household for private home viewing, from an authorized copy of the motion picture, or the creation or provision of a computer program or other technology that enables such making imperceptible and that is designed and marketed for such use at the direction of a member of a private household, if--
(A) no fixed copy of the altered version of the motion picture is created by such computer program or other technology; and
(B) no changes, deletions or additions are made by such computer program or other technology to commercial advertisements, or to network or station promotional announcements, that would otherwise be performed or displayed before, during or after the performance of the motion picture.';and...
It seems that one key clause in there is 'the making imperceptible' of the editing out of the commercial. Seems that if you got a 1 second 'commercials removed' screen then it might be OK?
RTFA. TFA is talking about the longevity of *formats*, not just media. Who can say that there will be MP3 decoder implementations in the year 2050 for your pristeen collection of digital songs?
Face it -- analog formats *and* media survive the ages longer. You have the capability to play an LP your parents purchased in the 50's. Likewise you can see pictures taken then and earlier, be they prints, negatives, slides, what have you.
But on the downside, they are inherently lossy and less-convienent (today) than digital media.
Adding to potential future despair, the proprietary 'raw' image formats coming from medium- to high-end cameras these days have a much higher potential for bitrot, since most of such formats are closed.
We can reasonably expect to still have software which can read, oh, say, TIFF and JPEG in the future due to their massive proliferation, but who is to say that Adobe Photoshop v.19 will still have a ~2004-era Canon RAW import tool.
I do believe that Adobe has proposed an open TIFF extension to encapsulate RAW images. I would hope that such a thing would take off.
That's quite useful advice. Worked like a champ on OSX also. You can also most likely get rid of the 'PrintMe' plugin, since this is not the internal File->Print feature, but, rather, some sort of newfangled 'print-to-any-internet-device' type printing suite -- a third-party plugin which probably skips the system printqueue altogether.
Well thanks for the clarification! I always thought that coding those 'filesystems' in the kernel must have been more difficult than doing the heavy lifting in user space. A little odd that FTP and WebDAV are handled through two separate mechanisms -- implemented at different times by different teams? Did NeXT support FTP as filesystem?
Is the age-old question of 'does it belong in the kernel'. OSX's webdav and FTP client support accessable from the finder, the analogues to KDE's FTP and webdav protocol plugins, are in reality implemented in the kernel as a filesystem implementation, making them useable from *every*single* application running on the box, not just the ones linked into a particular application framework (KDE). The OSX implementations are truly remote filesystems, upon which I can 'cd', and 'vi' myself into oblivion.
But the downside is that these 'fancy' network filesystems are comparatively sparse relative to KDEs. And we're still waiting for, oh, say, webdav over SSL support (making it actually worthwhile for an intranet filesystem solution).
IF OSX could have retainted the 'filesystem drivers as userspace processes' mantra of the microkernel design philosophy, then we could have the best of both worlds. Especially if we could retain, say, HPFS, FFS, etc. as kernel resident drivers for efficency .
You can surpass Windows DFS, providing a truly enterprise filesystem for both UNIXen and Windows, including unified namespace and read-only volume replication -- www.openafs.org.
It'll take some time to grok, but it can be done. Too bad AFS was a little too far-reaching for its day, but not much has come to touch it when you really need something like it.
Or doing thick-client things on a thin-client (i.e. browser).
Send a 'large' chunk of data down to the client -- more than what will be displayed currently, including the navigation rules (graph edges) between blocks of the chunk of data, so that the client itself can enable / remove available pathways (i.e. screen controls) to navigate through the data. This saves having to perform a server round trip per each choice the user makes.
The example use of such a novelty is their online car shopping site use. But it seems to equally cover arbitrary things done in HTML / Javascript, such as limiting the proper number of days in the month according to the month entered (30 days hath...).
This is not correct -- postgresql users who can create databases are *not* superusers. Those that can create other users are.
Regardless, as stated elsewhere, why would the general vhosted account be given either createdb or createuser privs?
Pre-set 'em up their own database + user account. Maybe even, if they're high dollar, give 'em access to a webapp which could create their own schemas within their database (only superusers can create schemas), and then they could go wild and crazy.
Well, as far as vendor-independent operating system standards, there was also the MS-DOS, PC-DOS, Concurrent-DOS family (any others in there offhand w/o consulting the wikipedia?). And from one perspective, the vedor lawsuit perspective, it was just as successful as the UNIX family.
But it was killed off by Windows 95 (or was it axed by dirty tricks in the Windows 3.X family? I dunno).
But perhaps it was because the UNIX family of vendor neutral (and hardware neutral) operating systems always targeted larger, multiuser machines, and end-user hardware at the PC level ended up being 'large' (hardware resource-wise) and multi-user (mom, dad, kids, maybe not concurrent as in the good old days of the university vax running 4.3BSD, but hey!) that let the initial design of UNIX still be pertinent today. And that the source code written on top of UNIX APIs is still relevant today.
Well, Rob did something different -- took what they learned from UNIX and wrote something new. And in his eyes, Plan 9 probably has way-fewer warts than POSIX.
I'm surprised this was modded troll. I'm a UNIX user since '92 or thereabouts, and have my FreeBSD 1.0 CD to show for it. Rob is textbook hard core old school, yet he decided to develop something decidedly *different* from UNIX. Therefore, he must have felt that something more radical was warranted than tacking on new substructures to the old warhorse. Cleaner and more interesting solutions were only possible through starting fresh.
Anyway, I was interested in his opinion of if UNIX deserves incremental change and updates, or if it, in his opinion, is ultimately a dead-end -- that our time would be better spent working on something that takes what was good from UNIX yet leaves the bad behind, just as UNIX did to MULTICS.
For example, Plan 9's per-process mount tables are definitely interesting, making more general a concept found in UNIX, but a much bolder change than what one would expect on a UNIX. Similar things can be said of Hurd's abandonment of the 'process running as root has all priviledges' concept. Likewise for languages whose system runtimes perform array bounds checking automatically.
Is all of the current effort maintaining implementations of the UNIX way worth it? More specifically, when should we finally cut our losses and stop living with design desicions which were made decades ago for hardware and user constraints which are not nearly as relevant now as they were when they were made?
Two reasons a common RAW / straight from CCD format would be good for the world:
Short term: Adobe's maintenance cost for their raw import plugin gets an upper bound, as opposed to potentially O(N) where N is each {CCD + camera vendor} tuple.
Long term: Longevity of Closed-format RAW files? Say Canon / Nikon / whoever goes under in year 2010. Say Adboe Photoshop ceases to run on my platform in year 2015. I'm left holding the bag of my countless Canon 'raw' CRW files, wishing I had shot film after all.
Straight from CCD files == A Good Thing with respect for total postprocessing control, as long as you have good support, say through the ACR plugin. But they're A Bad Thing with respect to most everything else -- such as guarantees that these files will be readable sometime in the future, or that you can process *your* images using non-ACR-plugin enabled tools (like, say, a homegrown 3-tier image cataloging suite).
And don't even ask about the vendor supplied RAW processing tools that can produce, say, a TIFF from a given RAW file. They usually *stink* with respect to performance, only work on Windows or Mac, and, finally, will have NO guarantee that such a tool will be available to me on my platform of choice in the year 2010.
Slashdot Mirror
I have to agree with the OP. We'll be living with big bloated Java systems well into the afterlife, just like we're living with the big bloated COBOL systems of yesteryears. Why? They're the same sort of systems.
Big 'enterprise' in-house systems which keep the business running. The COBOL ones which got re-written in the later 90s got rewritten to what -- Java. And they're not going to do that again for a good long time.
So, we've traded COBOL/VSAM for Java/EJB (shudder) or JDBC. Traded the expensive as hell VM system for an expensive as hell J2EE container. Or maybe JBoss.
And the folks getting rich doing the maintenance in 15 years will be the 'old timers' which still know Java / J2EE . And I pity them and their deployment descriptors.
I remember attending a presentation from Sun personel demoing their portal mail system, how they prided themselves at not competing with the application providers who develop for Solaris. I remember Oracle was mentioned specifically by name. They provided a counter-example in Microsoft, who produces both SQL-Server and the operating system.
Oh well.
So confused -- Sun becomes more evil by supporting PostgreSQL ?
Who cares about their sense of humor, it is their sense of history we'd like to see improved.
Which they released a 'legal', but value-added-only-for-microsoft extension, whose documentation was explicitly licensed as to prevent you from making an open-source interoperable equivalent.
AFAIR, anyway. Does SambaNG or whatever truly smell like an AD with the MS-KRB5 authorization field properly filled-in?
Yeah, all of that inline assembler code will now 'just work'. X11 versus Cocoa has absolutely _nothing_ to do with porting efforts, does it?
Our webshop develops on OSX (save one die-hard linux laptop uber-coder), then deploys production on SuSE/x86.
Best of both worlds. Now, this could slow down KDE / Gnome development (why bother 'suffering' under X11 anymore?), but at the same time it might well _aid_ the GNUStep project as folks want to get their newfound Cocoa apps running under Linux. Even with Webcore.
</ObHandWaving>
Then we could still clutch our warm fuzzy underground / alternative feelings.
Under OSX, I unpack the DMG on a test box, and if all looks good, I tar it up and cron out the update to all of our desktop boxes. The cron script tests the installed version's version string inside the plist file against the expected one, and, if not the same, then fetches the tarball from webspace and unpacks.
Social contract aside, AdBlock plugins and friends, if they become truly popular, will just cause the advertizements to become more and more inlined and camoflaged within the content of the site.
And so the arms race will up one notch, with the next generation of adblockers knowing how to filter those out too. Virus versus antivirus. Spam versus filters. Predator versus prey (but which is which exactly?).
I somewhat believe that a new flavor of turing test oughta be 100% spamblock capability with no false positives. Or automatic DVR commercial skipping. Or webpage adblocking. If it filters as well as I could these days, then slap an 'intelligent' badge on it and move on.
It's a bug which was present in Sun JVMS:
e y=1-26-57591-1&searchclause=57591
http://sunsolve.sun.com/search/document.do?assetk
Fixed in J2SE 5, J2SE 1.4.2_06, and J2SE 1.3.1_14.
AFAIK, there would be no cross-browser incompatibilities, since XSL / FO are server-side technologies.
From SEC. 212 of Cooperative Research and Technology Enhancement (CREATE) Act of 2004 (Reported in Senate)[H.R.2391.RS], available as http://thomas.loc.gov/cgi-bin/query/z?c108:H.R.239 1:/ ....
...
(3) by inserting after paragraph (10) the following:
(11) the making imperceptible, by or at the direction of a member of a private household, of limited portions of audio or video content of a motion picture, during a performance in or transmitted to that household for private home viewing, from an authorized copy of the motion picture, or the creation or provision of a computer program or other technology that enables such making imperceptible and that is designed and marketed for such use at the direction of a member of a private household, if--
(A) no fixed copy of the altered version of the motion picture is created by such computer program or other technology; and
(B) no changes, deletions or additions are made by such computer program or other technology to commercial advertisements, or to network or station promotional announcements, that would otherwise be performed or displayed before, during or after the performance of the motion picture.';and
It seems that one key clause in there is 'the making imperceptible' of the editing out of the commercial. Seems that if you got a 1 second 'commercials removed' screen then it might be OK?
He didn't even mention PostgreSQL. Smart, really, since PG is the 'true' opensource version of this codebase.
See http://en.wikipedia.org/wiki/Ingres the wikipedia for the gory details.
RTFA. TFA is talking about the longevity of *formats*, not just media. Who can say that there will be MP3 decoder implementations in the year 2050 for your pristeen collection of digital songs?
Face it -- analog formats *and* media survive the ages longer. You have the capability to play an LP your parents purchased in the 50's. Likewise you can see pictures taken then and earlier, be they prints, negatives, slides, what have you.
But on the downside, they are inherently lossy and less-convienent (today) than digital media.
Adding to potential future despair, the proprietary 'raw' image formats coming from medium- to high-end cameras these days have a much higher potential for bitrot, since most of such formats are closed.
We can reasonably expect to still have software which can read, oh, say, TIFF and JPEG in the future due to their massive proliferation, but who is to say that Adobe Photoshop v.19 will still have a ~2004-era Canon RAW import tool.
I do believe that Adobe has proposed an open TIFF extension to encapsulate RAW images. I would hope that such a thing would take off.
That's quite useful advice. Worked like a champ on OSX also. You can also most likely get rid of the 'PrintMe' plugin, since this is not the internal File->Print feature, but, rather, some sort of newfangled 'print-to-any-internet-device' type printing suite -- a third-party plugin which probably skips the system printqueue altogether.
YMMV.
Well thanks for the clarification! I always thought that coding those 'filesystems' in the kernel must have been more difficult than doing the heavy lifting in user space. A little odd that FTP and WebDAV are handled through two separate mechanisms -- implemented at different times by different teams? Did NeXT support FTP as filesystem?
Is the age-old question of 'does it belong in the kernel'. OSX's webdav and FTP client support accessable from the finder, the analogues to KDE's FTP and webdav protocol plugins, are in reality implemented in the kernel as a filesystem implementation, making them useable from *every*single* application running on the box, not just the ones linked into a particular application framework (KDE). The OSX implementations are truly remote filesystems, upon which I can 'cd', and 'vi' myself into oblivion.
But the downside is that these 'fancy' network filesystems are comparatively sparse relative to KDEs. And we're still waiting for, oh, say, webdav over SSL support (making it actually worthwhile for an intranet filesystem solution).
IF OSX could have retainted the 'filesystem drivers as userspace processes' mantra of the microkernel design philosophy, then we could have the best of both worlds. Especially if we could retain, say, HPFS, FFS, etc. as kernel resident drivers for efficency .
You can surpass Windows DFS, providing a truly enterprise filesystem for both UNIXen and Windows, including unified namespace and read-only volume replication -- www.openafs.org.
It'll take some time to grok, but it can be done. Too bad AFS was a little too far-reaching for its day, but not much has come to touch it when you really need something like it.
Or doing thick-client things on a thin-client (i.e. browser).
...).
Send a 'large' chunk of data down to the client -- more than what will be displayed currently, including the navigation rules (graph edges) between blocks of the chunk of data, so that the client itself can enable / remove available pathways (i.e. screen controls) to navigate through the data. This saves having to perform a server round trip per each choice the user makes.
The example use of such a novelty is their online car shopping site use. But it seems to equally cover arbitrary things done in HTML / Javascript, such as limiting the proper number of days in the month according to the month entered (30 days hath
Lovely.
This is not correct -- postgresql users who can create databases are *not* superusers. Those that can create other users are.
Regardless, as stated elsewhere, why would the general vhosted account be given either createdb or createuser privs?
Pre-set 'em up their own database + user account. Maybe even, if they're high dollar, give 'em access to a webapp which could create their own schemas within their database (only superusers can create schemas), and then they could go wild and crazy.
Well, as far as vendor-independent operating system standards, there was also the MS-DOS, PC-DOS, Concurrent-DOS family (any others in there offhand w/o consulting the wikipedia?). And from one perspective, the vedor lawsuit perspective, it was just as successful as the UNIX family.
But it was killed off by Windows 95 (or was it axed by dirty tricks in the Windows 3.X family? I dunno).
But perhaps it was because the UNIX family of vendor neutral (and hardware neutral) operating systems always targeted larger, multiuser machines, and end-user hardware at the PC level ended up being 'large' (hardware resource-wise) and multi-user (mom, dad, kids, maybe not concurrent as in the good old days of the university vax running 4.3BSD, but hey!) that let the initial design of UNIX still be pertinent today. And that the source code written on top of UNIX APIs is still relevant today.
Well, Rob did something different -- took what they learned from UNIX and wrote something new. And in his eyes, Plan 9 probably has way-fewer warts than POSIX.
I'm surprised this was modded troll. I'm a UNIX user since '92 or thereabouts, and have my FreeBSD 1.0 CD to show for it. Rob is textbook hard core old school, yet he decided to develop something decidedly *different* from UNIX. Therefore, he must have felt that something more radical was warranted than tacking on new substructures to the old warhorse. Cleaner and more interesting solutions were only possible through starting fresh.
Anyway, I was interested in his opinion of if UNIX deserves incremental change and updates, or if it, in his opinion, is ultimately a dead-end -- that our time would be better spent working on something that takes what was good from UNIX yet leaves the bad behind, just as UNIX did to MULTICS.
For example, Plan 9's per-process mount tables are definitely interesting, making more general a concept found in UNIX, but a much bolder change than what one would expect on a UNIX. Similar things can be said of Hurd's abandonment of the 'process running as root has all priviledges' concept. Likewise for languages whose system runtimes perform array bounds checking automatically.
Is all of the current effort maintaining implementations of the UNIX way worth it? More specifically, when should we finally cut our losses and stop living with design desicions which were made decades ago for hardware and user constraints which are not nearly as relevant now as they were when they were made?
Straight from CCD files == A Good Thing with respect for total postprocessing control, as long as you have good support, say through the ACR plugin. But they're A Bad Thing with respect to most everything else -- such as guarantees that these files will be readable sometime in the future, or that you can process *your* images using non-ACR-plugin enabled tools (like, say, a homegrown 3-tier image cataloging suite).
And don't even ask about the vendor supplied RAW processing tools that can produce, say, a TIFF from a given RAW file. They usually *stink* with respect to performance, only work on Windows or Mac, and, finally, will have NO guarantee that such a tool will be available to me on my platform of choice in the year 2010.