So that extra dollar gets you a physical disk... No, thanks. I have enough physical disks. Between Emusic, Amazon, ITMS (+ QTFairUse), and who-know-what-else-is-coming, I may never have to buy another CD again, ever.
If this bill passes into law (and isn't struck down by the Supreme Court), then for all intents and purposes, the Constitution of the United States is null and void.
There, I said it. Words cannot adequately describe how disgusting I think this is.
The carrot will be interoperability with Microsoft's stacks...
Is this really all that much of an incentive? I'm putting together a very-big-assed RHEL thingy that has no requirement to interoperate with any MS stacks (other than http, and that's hardly proprietary).
The website says that the roadshow is coming to Texas. I'm interested in the thing, but it better have a powerful air conditioner if it's going to sell in Texas.
My own experience shows that dynamic linking is too much to bear.
That's curious.
If you're doing any interop with system commands, local daemon, local facilities, etc., it may behoove you to use the same libraries that they use - and those would be the system-wide shared libraries. Also, if you plan to do field patching and your application consists of several programs that use the same application libraries, you can save yourself a lot of CM headaches by using shared libraries.
Suggest you read and understand the ld(1) man page, especially the '-rpath', '-h', and '-i' options.
So, you're volunteering to re-write (and test, and CM, and support) 25 years of existing code that already uses SysV semaphores -- to not use SysV semaphores and thus can be used with Java.
Please send your resume. It'll be nice to get free work.
What you're advocating is adoption of a single platform, the Java platform,...
This is a major problem with Java. If any part of a software system becomes Java, then eventually, because of the shortcomings of the Java implementation, the whole software system must become Java.
Thanks for the Java NIO info. But the load() and force() methods make it look like that this implementation copies to/from local memory from/to a file, rather than implementing a true mmap(2)ing ( See mmap(2) ). It's more or less how Perl implements mapping files, and isn't particularly useful.
Quote:
All the UNIX IPC methods are that: UNIX IPC. Not portable IPC, that would allow to make a portable Java implementation.
Portable? Irrelevant.
What I'm interested in is non-portable code in Java. Code that lets me easily use facilities provided by the operating sytem. The Java implementation doesn't allow for this (JNI, being multi-language, isn't useful).
Which part of "non-portable" don't you understand? For a single OS target, portability is useless.
Which, for single OS targets, is why Java is probably not a good choice of language. Not because of the language itself, but because of the implementation.
Well to be perfectly clear, I never used the word "hate" in any of these posts. I don't hate Java. I simply think that its implementation leaves a lot to be desired.
Great, now I have to develop in Java and C/C++ to get exactly the same capability that I can get by using C/C++ alone. At least with Perl/Python/etc. I get to use operating system facilities without having to go to a mixed language implementation.
Hardly a good solution. Have you ever had to deal with the CM issues with multi-language projects? No, thanks.
I don't hate Java the language, but Java the implementation leaves much to be desired:
Lack of support for UNIX-domain sockets
Lack of support for SysV semaphores
Lack of support for SysV shared memory
Lack of support for UNIX signals (other than SIGTERM)
Lack of any serious UNIX-style job control
Lack of any interface to map files into memory
Lack of any API to make system calls
In fact, the Java implementation suffers from a general lack of support for almost all of the standard UNIX IPC mechanisms, save INET sockets. How lame is that?
I'm sure a Win32 expert could rattle off a list of Win32 facilities that aren't supported by the Java implementation.
I know all this is all in the name of portability, and everyone agrees that portability is good. But if I know that my code is destined to run on only a single OS platform, shouldn't I be allowed to write non-portable code that lets me use facilities that are provided by the operating system?
Java the implementation doesn't support this, and this is why I'm reluctant to use Java.
Slashdot Mirror
Also, FSEvents. Not exactly groundbreaking, but very, very convenient. And a great solution to a nagging problem.
Then we win.
Generally? What if performance is your goal?
'nother middle-aged-Google-applicant here: I concur, although I didn't make it past the phone screen.
Oh, man, another hilarious post! excellent! keep 'em coming! how do you think this stuff up?
hilarious! great comment!
This makes me very happy.
... about why cross-platform development is such a big deal. You end up with a crippled, least-common solution that doesn't allow the use of operating system facilities.
If this bill passes into law (and isn't struck down by the Supreme Court), then for all intents and purposes, the Constitution of the United States is null and void.
There, I said it. Words cannot adequately describe how disgusting I think this is.
Exactly. And, moreover, the lesson from the DS is: It's not all about games.
The only "games" I play now, ever, are Electroplankton and Jam Sessions.
After using these, playing a normal game is pretty boring.
What kind of processor? Why, all of them.
You apparently don't work on gov't contracts.
Is this really all that much of an incentive? I'm putting together a very-big-assed RHEL thingy that has no requirement to interoperate with any MS stacks (other than http, and that's hardly proprietary).
The website says that the roadshow is coming to Texas. I'm interested in the thing, but it better have a powerful air conditioner if it's going to sell in Texas.
Oh, please.
What about emacs?
That's curious.
If you're doing any interop with system commands, local daemon, local facilities, etc., it may behoove you to use the same libraries that they use - and those would be the system-wide shared libraries. Also, if you plan to do field patching and your application consists of several programs that use the same application libraries, you can save yourself a lot of CM headaches by using shared libraries.
Suggest you read and understand the ld(1) man page, especially the '-rpath', '-h', and '-i' options.
Best of luck.
... it's just a couple of plain text metadata atomsAny decent hex editor (like emacs hexl-mode) ought to take care of those.
... should be enough to solve the problem until someone releases a one-liner perl script to strip away the account info.
So, you're volunteering to re-write (and test, and CM, and support) 25 years of existing code that already uses SysV semaphores -- to not use SysV semaphores and thus can be used with Java.
Please send your resume. It'll be nice to get free work.
This is a major problem with Java. If any part of a software system becomes Java, then eventually, because of the shortcomings of the Java implementation, the whole software system must become Java.
All the UNIX IPC methods are that: UNIX IPC. Not portable IPC, that would allow to make a portable Java implementation.Quote:
Portable? Irrelevant.
What I'm interested in is non-portable code in Java. Code that lets me easily use facilities provided by the operating sytem. The Java implementation doesn't allow for this (JNI, being multi-language, isn't useful).
Which part of "non-portable" don't you understand? For a single OS target, portability is useless.
Which, for single OS targets, is why Java is probably not a good choice of language. Not because of the language itself, but because of the implementation.
Well to be perfectly clear, I never used the word "hate" in any of these posts. I don't hate Java. I simply think that its implementation leaves a lot to be desired.
Great, now I have to develop in Java and C/C++ to get exactly the same capability that I can get by using C/C++ alone. At least with Perl/Python/etc. I get to use operating system facilities without having to go to a mixed language implementation.
Hardly a good solution. Have you ever had to deal with the CM issues with multi-language projects? No, thanks.
I'm sure a Win32 expert could rattle off a list of Win32 facilities that aren't supported by the Java implementation.
I know all this is all in the name of portability, and everyone agrees that portability is good. But if I know that my code is destined to run on only a single OS platform, shouldn't I be allowed to write non-portable code that lets me use facilities that are provided by the operating system?
Java the implementation doesn't support this, and this is why I'm reluctant to use Java.
World dominates robot!