The Apple Newton was a fascinating system design; the underpinnings were an advanced dynamic system providing scripting capabilities to the user along with pervasive use of persistent objects.
The "advanced link of the day" today is Oleg's Scheme Environments that add a hierarchical data store that consciously remembers NewtonScript "soups," which essentially represent a useful way of throwing "queries" from one place to another.
In contrast, while PalmOS does make pervasive use of persistent data, it doesn't have an equivalent to "soups."
The point here is that while "web slates" and the like may make neat "eye candy," some of the stuff Apple has discarded (and they had to discard Newton; they had lost the ability to maintain it...) is more advanced than some of the fancy things we think are k001 today.
That being said, I carry around a Palm III. Newtons were a bit too expensive, rather large, and, importantly today, the fact that they're complex critters that are not supportable by anyone because the technology was lost makes them unacceptable for future use...
On the one hand, it's pretty evident that the Borland license can't say anything restrictive about what you do with your own code.
Thus, the notion that the license implies that you can't use Borland C++ to compile a GPLed program is just silly. And if someone posted the story on that basis, this makes them irresponsible idiots.
What is, on the other hand, less clear, is what transformations C++ Builder can do on your code, and whether THAT could lead to Borland having the right to restrict what you do.
As of Bison version 1.24, we have changed the distribution terms for yyparse to permit using Bison's output in non-free programs. Formerly, Bison parsers could be used only in programs that were free software.
The other GNU programming tools, such as the GNU C compiler, have never had such a requirement. They could always be used for non-free software. The reason Bison was different was not due to a special policy decision; it resulted from applying the usual General Public License to all of the Bison source code.
The output of the Bison utility--the Bison parser file--contains a verbatim copy of a sizable piece of Bison, which is the code for the yyparse function. (The actions from your grammar are inserted into this function at one point, but the rest of the function is not changed.) When we applied the GPL terms to the code for yyparse, the effect was to restrict the use of Bison output to free software.
In similar manner, if you use C++ Builder to generate code, as might be the case if you used the Drag'n'Drool interfacing to generate GUI code, it is plausible that Borland might have something to say about what you do with the code that was generated by their code generator.
A responsible person would, before submitting this story, try to verify some such information, rather than generating an irresponsible drive-by flaming of Borland. Of course, a responsible person would, before accepting the story for publishing, do some modicum of verification.
Few, of course, would accuse Slashdot of being a place for responsible people.
The material that is in the article is very interesting; the BSD's have been decidedly underrated in their contributions.
But there are four things that the Salon article missed that I'd quite like to see a "central" presentation on:
The story of BSD 386, and the Fear Of Lawsuit.
Back in the late '80s, I saw some folks in Ottawa playing around with it, with some paranoia going on over whether the lawsuit-happy would be stamping it out.
The flowthrough to NetBSD versus FreeBSD versus BSDi
These started as varying approaches to the use of the "ashes" of BSD 386. I'm sure there's more of a story to it than that.
The establishment of OpenBSD
Perhaps with further commentary as to the "splits."
The final developments of 4.4 BSD Lite
Which had pretty big plans, notably including filesystem efforts (journalling FFS, tmpfs, and such).
It's not clear what, of the final efforts on the academic side, have headed into active versions.
Is part of the problem lack of machines?
on
New Mega Alphas
·
· Score: 5
If you look at the population of machines out there running Linux, the vast majority don't do SMP. (I've got an SMP box that's not doing SMP. Anyone have a spare IBM Intellistation Z Pro 'voltage regulator'?)
The natural result of that is that hacking on SMP stuff is not of top priority to the average person using Linux let alone those that are actively "kernel hacking."
That's a mouthful that effectively says "few people truly care about SMP."
Of those that do have SMP hardware, how many have more than 2 CPUs? My SMP motherboard has only slots for 2. The Slashdot What's a good motherboard for SMP Linux? discussion mostly found 2-way and 4-way SMP hardware.
Dual mobos are readily available and not too expensive. Quad mobos can be found (try pricewatch) but start in the thousands of dollars.
Recent pricing at PriceWatch indicates that quad Xeon mobos start around $2500, and that ignores CPUs.
Certainly consistent with these being very expensive puppies that there is, resultantly, relatively little experience with.
Soup it up to 8-way SMP, and the pricing obviously heads into the stratosphere, thus further discouraging the wide deployment that allows the "open source" principle that
Given enough eyeballs, all bugs are shallow.
If it costs $20K for the motherboard, and $100K for the system, that rather diminishes the number of "eyeballs."
I think I have to agree that Linux is unlikely to be as ready to take advantage of high end SMP hardware as VMS, "whatever they want to call Ultrix today," Irix, or Solaris.
It only will get much better when there's a goodly population of kernel hackers with 16-way Alpha boxes:-). (Drool...)
Alternatively, it would be rather cool if there was some platform where we could get "massively SMP" motherboards where the CPUs didn't have to be "massively expensive." I dunno what, exactly. StrongARM would be interesting, but I gather that it is not terribly supportive of SMP. MIPS looks like the architecture for which there exist both cheap CPUs and massively parallel systems ( e.g. - the SGI/Origin "Cray" boxes).
The Cobalt Qube and RaQ 2 products use the SGI MIPS processor, not ARM. (And the RaQ 3 uses an "Intel compatible" processor, according to the data sheets found here. )
I've seen information indicating expressions of interest in a port of PalmOS to StrongARM; I'll believe in there being product when I actually see it on store shelves.
This has nothing to do with the XFree86 code base.
The restrictions that the XFree86 team have on releasing source code have nothing to do with the non-freeness of Motif, and everything to do with the fact that hardware vendors sometimes release documentation for hardware on the basis of Non Disclosure Agreements.
Why would you think that the "partial freeing" of Motif would have anything at all to do with the activities of The XFree86 Project?
As for anti-aliasing font handling, there are two methods to implement this:
As an extension to the X protocol.
Perhaps in X11R6.5.
As an extension, this would mean that only new applications that are aware of the new extension would use the new font handling scheme.
As an extension to some existing libraries.
For instance, the GNOME "Canvas" appears to provide support for the use of anti-aliased fonts right now. Ditto for Display Postscript.
Of course, in order to use the antialiased facilities, applications have to be specifically coded to use things like GNOME Canvas or DPS. Existing applications don't get benefit of it "for free."
The only way that "legacy" applications would get any benefit from this extension is if they use libraries like GTK or Tk, and those libraries can be compatibly retrofitted to use anti-aliasing.
Again, this is a matter that is almost entirely irrelevant to the "opening up" of Motif source code.
The problem I see with the way LinuxCare tried to grow, massively, is that a critical factor in a "service" business is that of establishing working relationships.
Thus, getting the level of sales to increase by $100M/year requires convincing a goodly number of people that a working relationship is worth more than $100M/year.
The problem is that it's difficult to so quickly establish relationships of trust.
Others have pointed out Don Hopkins' page on NeWS, which appears to be the best remaining reference to NeWS on the web...
The Andrew WM has been pointed out...
I'm not sure that anyone has pointed out NeXTstep/OPENSTEP, which is probably the other major option that was considered highly innovative.
I don't think anyone has pointed out Fresco, which represents the "spiritual parent" of Berlin, which was the "free" toolkit for X that was ignored in favor of Motif, and provided standardized interfacing via IDL (which was not yet formalized as CORBA), as well as some interesting ways of organizing output presentation.
A common thread across all of these (perhaps save for Fresco) is that Licensing Is Really Important.
NeWS and NeXTstep and the "Andrew thing" all had some technical merits that were overruled by licensing constraints. They were owned by major companies (Sun, NeXT, IBM), and in the scramble to maximize revenue, and, more importantly, maximize control, the notion of them having the potential to become industry-wide schemes was lost. (Microsoft took a different tack with Win32; MSFT fought long, hard, and nasty to ensure that their software would be dominant. If you can dominate, you don't need to "share" to see your system go industry-wide. Insert visions of leather-clad Bill Gates with a whip here... )
The "N" guys had a further constraint, that being that they both had dependancies on Display Postscript, from Adobe. The only way they could become ubiquitous was for Adobe to become more ubiquitous. Some of Apple's troubles in getting "Rhapsody/MacOS-X" released relate to that in that it appears Adobe has concluded they'd rather not sell DPS.
Fresco, in contrast, got "shafted" in the political wars between the UNIX vendors. It wasn't proprietary enough for their liking at the time, or so it would appear. I have a feeling that the UNIX world would be considerably different today if Fresco had been chosen over Motif...
The notion that TCP winds up transmitting some "header" info that doesn't always get recomputed presents an obvious instance of this; it is only covert to those that don't properly understand TCP/IP.
The relevance of mentioning "Big Iron" is that this is what made Ellison rich.
Oracle doesn't get its revenue flows from selling Network Computers with StrongARM chips; that was a loss. It makes its money off selling licenses and services for the DBMS products.
I will believe that PostgreSQL (which is quite distinct from Postgres ) has "serious corporate backing," as compared to ODS, when we see availability of at least two of the following:
An XA interface is produced for PostgreSQL
Tuxedo becomes available for PostgreSQL
MQSeries becomes available for PostgreSQL
Talarian becomes available for PostgreSQL
Tibco TIB becomes available for PostgreSQL
Tengah becomes available for PostgreSQL
R/3 can run atop PostgreSQL
PeopleSoft can run atop PostgreSQL
Those are good examples of "enterprise" software that integrates with ODS and (on the middleware side) are used to allow ODS to be used to build very large scalable applications.
Substitute MySQL for PostgreSQL as needed here...
By the way, Michael Stonebraker answered the question, Is there a connection between the Ingres and Postgres projects? back in 1994 with the clear answer of NO .
The problem with a "NC" where no storage sits locally is that this means that your applications are 100% dependant on the reliability of the network connection betwixt you and where ever storage resides.
With the limited reliability of ISP connections, that is a severely dangerous dependancy.
What if...
You get half-way done work on a "Oracle Word Processor" document, haven't saved it recently, and then the ISP connection goes wonky?
Ditto for any application that saves documents as complete files ?
If Oracle provides a set of "databased applications," where documents are "saved" based on pushing DB updates out to a networked database, where updates are pushed out ASAP, that may be one thing. (One thing that assumes applications that we don't know, with any certainty, exist.)
Supposing that scenario is true, and there is some persistent local storage where updates can be queued if the network connection goes down, that's a bit better still.
But unless there's a whole lot more to "Oracle Office Applications" than impressions suggest (the last I heard, Oracle Office was a somewhat lame mail client reminiscent of the email functions of Lotus Notes), the overall system would resultantly be LESS RELIABLE THAN MS-WINDOWS.
And the only way for it to be wonderfully reliable would be if there was a set of terribly proprietary Oracle Applications that would tie your documents quite forcibly to sitting at Oracle. A situation rather scarier than the present one of documents being held hostage to What Format Will Microsoft Make You Use Today?
I just don't see this working out. The reasoning not fully agreeing with yours, but the conclusions certainly being similar...
To some extent, the "Ellison Effect" is more self-defeating.
The fact that Oracle licensing fees are more blatantly large makes it rather clearer that Oracle is out to Take Care Of Your Money (by putting it in their bank account!), which shows off the clear need to periodically use other vendors' DBMSes.
The other fortunate thing is that Oracle primarily is connected to selling Big Databases, which is something that only people with big chequebooks tend to get involved with.
There is not any reasonable likelihood of any of the "libre" options ( e.g. - PostgreSQL, InterBase, MySQL, ... becoming reasonable alternatives at the Big Iron / Enterprise end of things any time soon, although they may become quite reasonable choices for "small, departmental" applications.
All you need to do is to look at the licensing of Designer 2000 and see how while the fees may rise exponentially, this results in a die-off of deployment amongst anyone that doesn't have deep pockets...
You can, indeed, set up all the appropriate daemons to provide all sorts of "standard" services, of which LDAP is certainly one.
The problem is that starting up the LDAP daemon does not intrinsically provide you with any useful functionality. You have to have some separate setup done to put some useful data into the LDAP database.
Thus, it's not terribly useful to have the LDAP server there unless it is usable for (say) user authentication, which would mean that you need some code that pushes data from (say) /etc/passwd into the LDAP database.
Likewise, an LPD server is devoid of functionality until there is some information pushed into /etc/printcap to configure some printers. And from there, for this to be of use to SAMBA users, some configuration has to be pushed into the SAMBA configuration to "publish" the print queues from /etc/printcap there.
There in effect need to be some "self-discovery" mechanisms that search the system for capabilities, and "publish" them as "public" network services.
The big problem with this is that it is likely to defy standardization due either to:
Local customizations ( e.g. - where I set up some "internal" print queues that are not for public consumption) or
Local security considerations ( e.g. - where certain user IDs shouldn't get "published" as they are private to the server.)
The primary reason to assign copyright to the FSF is that this allows the FSF to pursue lawsuits against nefarious scofflaws that might wish to do things contrary to the GPL with the code.
If you have deep pockets, and can fight your own legal battles, this may be a non-issue.
If you dislike the GPL or the FSF, then this is obviously a non-issue.
If you specifically wish to take an opposite approach, of having each author of bits of the code base be responsible for copyright holding of "their bit," that takes a different approach. (As is true for the Linux kernel.)
Note that contrary to fairly common paranoid fantasies to the contrary, the author can always retain a non-exclusive copyright, as per the assignment agreement:
Upon thirty days' prior written notice, the Foundation agrees to grant me non-exclusive rights to use the Work (i.e. my changes and enhancements, not the program which I enhanced) as I see fit; (and the Foundation's rights shall otherwise continue unchanged).
If the use of profiling led to advertisers sending out more "carefully" targeted material, thus outright diminishing the amount of spurious advertising going out, that would be one thing.
Unfortunately, reality is another.
Profiling is most likely used to increase the prices gotten for selling mailing lists. Which may merely mean that the "valued" mailing lists get used more , thus meaning you get more junk mail, and possibly cluelessly so.
I bought something from "MacWarehouse" a couple years ago, so I'm now apparently profiled as a rabid buyer of MacOS material. Like clockwork, I get another catalogue from them every three to four weeks.
Parallel this with the "profiling" being done of "disaffected youth" in the aftermath of the Columbine shootings. For a little while there, the "mass opinion" was that anyone wearing a trenchcoat to school was a mass murderer about to be.
Even with more careful collection of information, the sorts of evidences that are visible enough to make useful 'profile' criteria are loose enough to result in horrendous "false positive" statistics. That is, the profiles will result in immense quantities of innocents being tagged as potential mass murderers.
If such crucial life-and-death matters can be gotten so wrong, why is it reasonable to expect that there will be more competence applied to the question of whether you are a good candidate for an ad for a new kind of feminine hygiene product?
It's quite funny that there's a lawsuit against the DoubleClick folks; it is not at all obvious what the resolution ought to be. There may be poetic justice involved, but it is entirely possible that a judgement against DoubleClick could be a bad legal result, representing an ill wind moving forwards...
I hear rumor that NIAL, an APL with with a Lisp-like syntax, offers the ability to run it in CGI apps...
So, for those that feel the need to write web apps using reduction operators, preferably without ever using the diamond operator ( looping! ), it seems rather likely that there are some options available. Perfect for making use of that IBM 360 you picked up on eBay...
I somewhat think I'd rather do my APL reduction work by way of the Common Lisp (reduce #'whatever-function whatever-list) function, mind you....
It's well and nice to have this release; it has two significant problems:
$800 is rather expensive.
Hopefully competition and time will bring the cost, and thus, the price, down.
It's inflexible in what output is permitted.
I find it rather useful that my Diamond Rio can be treated as a 64MB "silicon disk" via use of the SnowBlind RIO utility , rio .
In contrast, according to the PjBox FAQ , there's no reasonable way of getting digital data off the unit.
Ignoring, of course, the notion of encoding other sorts of data into MP3, and then doing a modem-like demodulation of that back into digital data, which would take additional hardware and the entertainment of building a suitable error-correcting protocol that can cope with there being no feedback from PC back to MP3 player.
The data dumps of structure and content represent about 110MB of data. That appears to be compressed; uncompressed could be quite a lot bigger.
This means that it is impractical for me to dump dmoz.org, although it would surely be reasonable for someone with a T1 to do a mirror on, say, a weekly basis.
I'd think archiving it would be wise anyways; it guards against various risks, not merely a change of AOL policy.
It guards against all sorts of outages, whether chosen ( e.g. - license change) or not (fire in the server room).
I would expect the same to be true for VA Linux Systems' SourceForge ; it would be a good thing for people interested in particular projects to do regular CVS archive retrievals so that if an asteroid strikes the Silly Valley, there may be copies of the code elsewhere.
Herein lies my skepticism about SourceForge; I'm not overly worried about them "taking things proprietary," but am rather a bit paranoid about backup procedures. In particular, the lack of visibility of policy on the subject. Maybe I just haven't looked hard enough...
Are you sure that this board will eliminate that control? In more than the short term?
It sure looks like the overall set of hardware is the same set that the vendors of all the MP3 players are using.
It seems likely to me that this is not merely "similar" hardware, but really is the same hardware. And if that be the case, once the MPAA foists "copy control clients" on the industry, those clients will be happy to update the "firmware" on the MP3 players, whether they're boxed units from Sony or Panasonic, or a custom job that you built yourself.
Not that it'shoul affect my Diamond Rio; I use the open source "SnowBlind Alliance" interface software, and merely upload files.
I'm afraid I don't see all that much value to this; to have yet another Diamond Rio clone just doesn't seem all that valuable.
(Is it me, or do others detect a "glut" of designs that are almost identical to the Rio?)
I don't see much point in having to integrate my own "Rio" when it provides no more functionality.
If the design provided some reasonable way of storing 1GB of data, cheaply, that sure would be interesting.
But another "me too!" design integrating together a synthesizer, some simple CPU/DSP, parallel interface, and a 32MB chunk of "flash" memory just does not excite.
Obviously this isn't a solution that provides k001 James Bond-style hardware like GPS, radio transmitters and such.
What I have long felt is that something like Lotus Notes is the right answer to the "laptop theft" problem.
Lotus Notes offers three major facilities that are helpful:
It provides an explicit "document management" system as its substrate.
It actually has parallels to NNTP news, the way Slashdot should operate... which leads to...
A simple "data replication" mechanism. If all your documents are set up as Notes Documents, in a Notes Database, they can spawn other applications to view/modify them as needed, but, once you save them, they sit in a database, ready to be replicated.
You are at the office, plug the laptop into the network, and select Replicate. It synchronizes the state of the database on the laptop with the state of the database on the LAN.
This means that if the laptop is stolen, all it takes to get the new one repopulated is to run Notes, connect to the appropriate databases, and select Replicate, and the laptop will get loaded up again. (Ready to be stolen again!)
The fact that it's a single database provides, as a natural direction...
The use of encryption to protect the databases from intruders.
If all the data sits in the Notes databases, and they are encrypted, on the laptop, then the nefarious Laptop Thief may have a slick new laptop, but will not have an easy time getting at the secret information on the laptop.
Linux offers things like CFS, the "Cryptographic Filesystem," which may allow filesystems to be kept secure. (I thus protect a partition or two on my laptop.) The thing that it misses is the "data synchronization" ability that Lotus Notes "replication" provides.
I want the numberic crap to GO AWAY. It's stupid, it's unmaintainable, and I do _not_ want to have the same old "device number" problems in new guises.
A hierarchical name-space with true names is the obviously correct way to name kernel parameters. And doing that any other way than exporting it as a filesystem is stupid and wrong.
Guys, remember what made UNIX successful, and Plan-9 seductive? The "everything is a file" notion is a powerful notion, and should NOT be dismissed because of some petty issues with people being too lazy to parse a full name.
The same is true of ASCII contents. Binary files for configuration data are BAD. This is true for kernel interfaces the same way it is true of interfaces outside the kernel.
I tell you, you don't want the mess of having things like the Windows registry - we want to have dot-files that are ASCII, and readable with a regular editor, that you can do grep's on, and that can be manipulated easily with perl.
This is one of those things that shows that Linus most definitely does have a clue. Further devfs changes will likely have an impact on VFS code, and thus be "injurious" to Alexander Viro. And it looks like there may be some side-effects whereby /proc gets nearly "reimplemented." And I can see the glimmerings of the VFS changes providing the kernel support needed to make managing ACLs and kernel capabilities a whole lot better.
It may take some time, and may not be complete until 2.5, but there is definitely some ongoing Good Stuff getting implemented in the Linux kernel.
Slashdot Mirror
The "advanced link of the day" today is Oleg's Scheme Environments that add a hierarchical data store that consciously remembers NewtonScript "soups," which essentially represent a useful way of throwing "queries" from one place to another.
In contrast, while PalmOS does make pervasive use of persistent data, it doesn't have an equivalent to "soups."
The point here is that while "web slates" and the like may make neat "eye candy," some of the stuff Apple has discarded (and they had to discard Newton; they had lost the ability to maintain it...) is more advanced than some of the fancy things we think are k001 today.
That being said, I carry around a Palm III. Newtons were a bit too expensive, rather large, and, importantly today, the fact that they're complex critters that are not supportable by anyone because the technology was lost makes them unacceptable for future use...
Thus, the notion that the license implies that you can't use Borland C++ to compile a GPLed program is just silly. And if someone posted the story on that basis, this makes them irresponsible idiots.
What is, on the other hand, less clear, is what transformations C++ Builder can do on your code, and whether THAT could lead to Borland having the right to restrict what you do.
People may remember back to the days of Bison before version 1.24. From the Conditions for Using Bison:
In similar manner, if you use C++ Builder to generate code, as might be the case if you used the Drag'n'Drool interfacing to generate GUI code, it is plausible that Borland might have something to say about what you do with the code that was generated by their code generator.
A responsible person would, before submitting this story, try to verify some such information, rather than generating an irresponsible drive-by flaming of Borland. Of course, a responsible person would, before accepting the story for publishing, do some modicum of verification.
Few, of course, would accuse Slashdot of being a place for responsible people.
But there are four things that the Salon article missed that I'd quite like to see a "central" presentation on:
Back in the late '80s, I saw some folks in Ottawa playing around with it, with some paranoia going on over whether the lawsuit-happy would be stamping it out.
These started as varying approaches to the use of the "ashes" of BSD 386. I'm sure there's more of a story to it than that.
Perhaps with further commentary as to the "splits."
Which had pretty big plans, notably including filesystem efforts (journalling FFS, tmpfs, and such).
It's not clear what, of the final efforts on the academic side, have headed into active versions.
The natural result of that is that hacking on SMP stuff is not of top priority to the average person using Linux let alone those that are actively "kernel hacking."
That's a mouthful that effectively says "few people truly care about SMP."
Of those that do have SMP hardware, how many have more than 2 CPUs? My SMP motherboard has only slots for 2. The Slashdot What's a good motherboard for SMP Linux? discussion mostly found 2-way and 4-way SMP hardware.
Recent pricing at PriceWatch indicates that quad Xeon mobos start around $2500, and that ignores CPUs.
Certainly consistent with these being very expensive puppies that there is, resultantly, relatively little experience with.
Soup it up to 8-way SMP, and the pricing obviously heads into the stratosphere, thus further discouraging the wide deployment that allows the "open source" principle that
If it costs $20K for the motherboard, and $100K for the system, that rather diminishes the number of "eyeballs."
I think I have to agree that Linux is unlikely to be as ready to take advantage of high end SMP hardware as VMS, "whatever they want to call Ultrix today," Irix, or Solaris.
It only will get much better when there's a goodly population of kernel hackers with 16-way Alpha boxes :-). (Drool...)
Alternatively, it would be rather cool if there was some platform where we could get "massively SMP" motherboards where the CPUs didn't have to be "massively expensive." I dunno what, exactly. StrongARM would be interesting, but I gather that it is not terribly supportive of SMP. MIPS looks like the architecture for which there exist both cheap CPUs and massively parallel systems ( e.g. - the SGI/Origin "Cray" boxes).
I've seen information indicating expressions of interest in a port of PalmOS to StrongARM; I'll believe in there being product when I actually see it on store shelves.
The restrictions that the XFree86 team have on releasing source code have nothing to do with the non-freeness of Motif, and everything to do with the fact that hardware vendors sometimes release documentation for hardware on the basis of Non Disclosure Agreements.
Why would you think that the "partial freeing" of Motif would have anything at all to do with the activities of The XFree86 Project?
Perhaps in X11R6.5.
As an extension, this would mean that only new applications that are aware of the new extension would use the new font handling scheme.
For instance, the GNOME "Canvas" appears to provide support for the use of anti-aliased fonts right now. Ditto for Display Postscript.
Of course, in order to use the antialiased facilities, applications have to be specifically coded to use things like GNOME Canvas or DPS. Existing applications don't get benefit of it "for free."
The only way that "legacy" applications would get any benefit from this extension is if they use libraries like GTK or Tk, and those libraries can be compatibly retrofitted to use anti-aliasing.
Again, this is a matter that is almost entirely irrelevant to the "opening up" of Motif source code.
Thus, getting the level of sales to increase by $100M/year requires convincing a goodly number of people that a working relationship is worth more than $100M/year.
The problem is that it's difficult to so quickly establish relationships of trust.
The Andrew WM has been pointed out...
I'm not sure that anyone has pointed out NeXTstep/OPENSTEP, which is probably the other major option that was considered highly innovative.
I don't think anyone has pointed out Fresco, which represents the "spiritual parent" of Berlin, which was the "free" toolkit for X that was ignored in favor of Motif, and provided standardized interfacing via IDL (which was not yet formalized as CORBA), as well as some interesting ways of organizing output presentation.
A common thread across all of these (perhaps save for Fresco) is that Licensing Is Really Important.
NeWS and NeXTstep and the "Andrew thing" all had some technical merits that were overruled by licensing constraints. They were owned by major companies (Sun, NeXT, IBM), and in the scramble to maximize revenue, and, more importantly, maximize control, the notion of them having the potential to become industry-wide schemes was lost. (Microsoft took a different tack with Win32; MSFT fought long, hard, and nasty to ensure that their software would be dominant. If you can dominate, you don't need to "share" to see your system go industry-wide. Insert visions of leather-clad Bill Gates with a whip here... )
The "N" guys had a further constraint, that being that they both had dependancies on Display Postscript, from Adobe. The only way they could become ubiquitous was for Adobe to become more ubiquitous. Some of Apple's troubles in getting "Rhapsody/MacOS-X" released relate to that in that it appears Adobe has concluded they'd rather not sell DPS.
Fresco, in contrast, got "shafted" in the political wars between the UNIX vendors. It wasn't proprietary enough for their liking at the time, or so it would appear. I have a feeling that the UNIX world would be considerably different today if Fresco had been chosen over Motif...
You know, this "power to terminate" might not be all bad!
Identified channels include:
- Space exhaustion
- Unmounting of busy system channels
- Contention for devices like printers
- Timing of processes
The notion that TCP winds up transmitting some "header" info that doesn't always get recomputed presents an obvious instance of this; it is only covert to those that don't properly understand TCP/IP.I think you didn't read what I wrote.
I didn't say "A lame email client like Lotus Notes. "
I wrote "somewhat lame mail client reminiscent of the email functions of Lotus Notes."
Why you projected into that the notion that I'm calling Lotus Notes "lame" escapes me. I said nothing about the qualities of Lotus Notes.
Oracle doesn't get its revenue flows from selling Network Computers with StrongARM chips; that was a loss. It makes its money off selling licenses and services for the DBMS products.
Those are good examples of "enterprise" software that integrates with ODS and (on the middleware side) are used to allow ODS to be used to build very large scalable applications.
Substitute MySQL for PostgreSQL as needed here...
By the way, Michael Stonebraker answered the question, Is there a connection between the Ingres and Postgres projects? back in 1994 with the clear answer of NO .
With the limited reliability of ISP connections, that is a severely dangerous dependancy.
What if...
If Oracle provides a set of "databased applications," where documents are "saved" based on pushing DB updates out to a networked database, where updates are pushed out ASAP, that may be one thing. (One thing that assumes applications that we don't know, with any certainty, exist.)
Supposing that scenario is true, and there is some persistent local storage where updates can be queued if the network connection goes down, that's a bit better still.
But unless there's a whole lot more to "Oracle Office Applications" than impressions suggest (the last I heard, Oracle Office was a somewhat lame mail client reminiscent of the email functions of Lotus Notes), the overall system would resultantly be LESS RELIABLE THAN MS-WINDOWS.
And the only way for it to be wonderfully reliable would be if there was a set of terribly proprietary Oracle Applications that would tie your documents quite forcibly to sitting at Oracle. A situation rather scarier than the present one of documents being held hostage to What Format Will Microsoft Make You Use Today?
I just don't see this working out. The reasoning not fully agreeing with yours, but the conclusions certainly being similar...
The fact that Oracle licensing fees are more blatantly large makes it rather clearer that Oracle is out to Take Care Of Your Money (by putting it in their bank account!), which shows off the clear need to periodically use other vendors' DBMSes.
The other fortunate thing is that Oracle primarily is connected to selling Big Databases, which is something that only people with big chequebooks tend to get involved with.
There is not any reasonable likelihood of any of the "libre" options ( e.g. - PostgreSQL, InterBase, MySQL, ... becoming reasonable alternatives at the Big Iron / Enterprise end of things any time soon, although they may become quite reasonable choices for "small, departmental" applications.
All you need to do is to look at the licensing of Designer 2000 and see how while the fees may rise exponentially, this results in a die-off of deployment amongst anyone that doesn't have deep pockets...
The problem is that starting up the LDAP daemon does not intrinsically provide you with any useful functionality. You have to have some separate setup done to put some useful data into the LDAP database.
Thus, it's not terribly useful to have the LDAP server there unless it is usable for (say) user authentication, which would mean that you need some code that pushes data from (say) /etc/passwd into the LDAP database.
Likewise, an LPD server is devoid of functionality until there is some information pushed into /etc/printcap to configure some printers. And from there, for this to be of use to SAMBA users, some configuration has to be pushed into the SAMBA configuration to "publish" the print queues from /etc/printcap there.
There in effect need to be some "self-discovery" mechanisms that search the system for capabilities, and "publish" them as "public" network services.
The big problem with this is that it is likely to defy standardization due either to:
Note that contrary to fairly common paranoid fantasies to the contrary, the author can always retain a non-exclusive copyright, as per the assignment agreement:
Unfortunately, reality is another.
Profiling is most likely used to increase the prices gotten for selling mailing lists. Which may merely mean that the "valued" mailing lists get used more , thus meaning you get more junk mail, and possibly cluelessly so.
I bought something from "MacWarehouse" a couple years ago, so I'm now apparently profiled as a rabid buyer of MacOS material. Like clockwork, I get another catalogue from them every three to four weeks.
Parallel this with the "profiling" being done of "disaffected youth" in the aftermath of the Columbine shootings. For a little while there, the "mass opinion" was that anyone wearing a trenchcoat to school was a mass murderer about to be.
Even with more careful collection of information, the sorts of evidences that are visible enough to make useful 'profile' criteria are loose enough to result in horrendous "false positive" statistics. That is, the profiles will result in immense quantities of innocents being tagged as potential mass murderers.
If such crucial life-and-death matters can be gotten so wrong, why is it reasonable to expect that there will be more competence applied to the question of whether you are a good candidate for an ad for a new kind of feminine hygiene product?
It's quite funny that there's a lawsuit against the DoubleClick folks; it is not at all obvious what the resolution ought to be. There may be poetic justice involved, but it is entirely possible that a judgement against DoubleClick could be a bad legal result, representing an ill wind moving forwards...
Unfortunately, ISAP - Information Server Auxiliary Processor from Dyadic Software offers APL integration only with MSFT IIS, and does not run them as CGI programs.
On the other hand, German speakers might find something useful at Sergy Alpin's JUMP page
I hear rumor that NIAL, an APL with with a Lisp-like syntax, offers the ability to run it in CGI apps...
So, for those that feel the need to write web apps using reduction operators, preferably without ever using the diamond operator ( looping! ), it seems rather likely that there are some options available. Perfect for making use of that IBM 360 you picked up on eBay...
I somewhat think I'd rather do my APL reduction work by way of the Common Lisp (reduce #'whatever-function whatever-list) function, mind you....
Hopefully competition and time will bring the cost, and thus, the price, down.
I find it rather useful that my Diamond Rio can be treated as a 64MB "silicon disk" via use of the SnowBlind RIO utility , rio .
In contrast, according to the PjBox FAQ , there's no reasonable way of getting digital data off the unit.
Ignoring, of course, the notion of encoding other sorts of data into MP3, and then doing a modem-like demodulation of that back into digital data, which would take additional hardware and the entertainment of building a suitable error-correcting protocol that can cope with there being no feedback from PC back to MP3 player.
This means that it is impractical for me to dump dmoz.org, although it would surely be reasonable for someone with a T1 to do a mirror on, say, a weekly basis.
I'd think archiving it would be wise anyways; it guards against various risks, not merely a change of AOL policy.
It guards against all sorts of outages, whether chosen ( e.g. - license change) or not (fire in the server room).
I would expect the same to be true for VA Linux Systems' SourceForge ; it would be a good thing for people interested in particular projects to do regular CVS archive retrievals so that if an asteroid strikes the Silly Valley, there may be copies of the code elsewhere.
Herein lies my skepticism about SourceForge; I'm not overly worried about them "taking things proprietary," but am rather a bit paranoid about backup procedures. In particular, the lack of visibility of policy on the subject. Maybe I just haven't looked hard enough...
It sure looks like the overall set of hardware is the same set that the vendors of all the MP3 players are using.
It seems likely to me that this is not merely "similar" hardware, but really is the same hardware. And if that be the case, once the MPAA foists "copy control clients" on the industry, those clients will be happy to update the "firmware" on the MP3 players, whether they're boxed units from Sony or Panasonic, or a custom job that you built yourself.
Not that it'shoul affect my Diamond Rio; I use the open source "SnowBlind Alliance" interface software, and merely upload files.
(Is it me, or do others detect a "glut" of designs that are almost identical to the Rio?)
I don't see much point in having to integrate my own "Rio" when it provides no more functionality.
If the design provided some reasonable way of storing 1GB of data, cheaply, that sure would be interesting.
But another "me too!" design integrating together a synthesizer, some simple CPU/DSP, parallel interface, and a 32MB chunk of "flash" memory just does not excite.
What I have long felt is that something like Lotus Notes is the right answer to the "laptop theft" problem.
Lotus Notes offers three major facilities that are helpful:
It actually has parallels to NNTP news, the way Slashdot should operate... which leads to...
You are at the office, plug the laptop into the network, and select Replicate. It synchronizes the state of the database on the laptop with the state of the database on the LAN.
This means that if the laptop is stolen, all it takes to get the new one repopulated is to run Notes, connect to the appropriate databases, and select Replicate, and the laptop will get loaded up again. (Ready to be stolen again!)
The fact that it's a single database provides, as a natural direction...
If all the data sits in the Notes databases, and they are encrypted, on the laptop, then the nefarious Laptop Thief may have a slick new laptop, but will not have an easy time getting at the secret information on the laptop.
Linux offers things like CFS, the "Cryptographic Filesystem," which may allow filesystems to be kept secure. (I thus protect a partition or two on my laptop.) The thing that it misses is the "data synchronization" ability that Lotus Notes "replication" provides.
The result of the massive changes is likely to be a diminishment of the amount of time Al Viro has available for other things, such as sleeping...
Incidentally, the portion of the Kernel Traffic discussion where Linus discusses devfs , mentioning thus:
This is one of those things that shows that Linus most definitely does have a clue. Further devfs changes will likely have an impact on VFS code, and thus be "injurious" to Alexander Viro. And it looks like there may be some side-effects whereby /proc gets nearly "reimplemented." And I can see the glimmerings of the VFS changes providing the kernel support needed to make managing ACLs and kernel capabilities a whole lot better.
It may take some time, and may not be complete until 2.5, but there is definitely some ongoing Good Stuff getting implemented in the Linux kernel.