According to this article in the Boston Globe
(an archive article which unfortunately requires both registration and a
$2.50 charge.)
Has the following passage:
The bill cleared the House in March 1998 but stalled in the Senate. Finally, in October, just before the end of the congressional term, a similar version reached the Senate floor, passed by unanimous consent, and cleared the House the same day in a voice vote. No members of Congress had to go on record with their votes.
There is an area between the two extremes of "Over the top" and "subtle". There are the types of jokes that sound odd enough to get you to read them, while reading are full of enough details that you start believing it. It isn't until the end of the story when the claims are getting more and more outlandish that you finally realize that it is a joke. Basically:
If the reader will realize it is a joke before they start reading, it isn't a good April Fools Day joke.
If most people won't realize it is a joke by the end of the article, it isn't a good April Fools Day joke.
There are a few systems that are entirely content production oriented and create flat HTML as their output. For commercial systems, Interwoven fits that criteria on the high end (except for their "web accelerators.") and companies like Red Dot on the low end.
I attended a talk earlier this year given by Andy McKay from Activestate describing their use of Zope on activestate.com. Basically for one portion of their site they develop all their software on Zope on their development server, export it all to flat files and push it to their production side.
So just because a CMS wants to be a web server, that doesn't mean it has to the a production web server.
Souped up isn't quite accurate. I'd call it relabled. The only difference between nCompass 4.0 and MS-CMS 2001 was the removal of the Oracle DBMS interface.
Some of Microsoft's marketing blurbs will try to confuse the issue. (with statements like "XML is an important part of Microsoft's.NET strategy. MS CMS supports XML natively.")
You view of what is trivial resources is based specifically current manufacturing technology and economics. The 256K that explorer.exe takes on my windows box would be unreasonable 5 years ago.
To reach the current state of GUI file managers, they (the same they that you were referring to.) that basing the system on recalling visual cues over remembering commands gave certain advantages to a certain group of users. I'd consider this an experiment in whether a spatial cues help or hinder the users navigation of the system.
By the time this research manifests itself as a marketable product, it might not be a 3D browser any more. It might just be that some facet of this app makes someone figure out how to create a single paned view that can show disparate parts of the file system hierarchy.
This reminds me a bit about an argument I had with a friend of mine about Lingua::Romana::Perligata. He couldn't see the package as anything but a waste of time, programming in a dead natural language. The point that I tried to make about the library isn't simply to write programs in latin. It could be viewed as an experiment in determining whether programming languages are required to be positionally dependent. If the results from Lingua::Romana::Perligata showed that there were significant advantages from determining syntax from inflection rather than position, a new syntax (not based on dead languages) could be developed by someone creating a commercial product.
Almost all of those arguments ( excessive system resources, fewer files directly accessible, and fewer actions that can be taken on those files) can be used in discussing the Unix shell environment vs the Macintosh Finder.
The "fly over the documents" metaphor has been tried before. In some ways it was the precursor to the office metaphor used for the Macintosh (As noted in the Son of Dataland section of the paper Inventing the Lisa User Interface
It might not be a matter of not caring, but some people are perfectly aware of the effects of allowing companies to collect profiling data and still have differing opinions on its merits.
I know someone who nearly will go out of their way to collect any sort of "preferred customer" card, rebate, or other sort of marketing/profiling collection scheme. Their view is "If companies are going to pay me money to cater their products to what I'm most likely to purchase. I'll tell them anything they want to know."
Postscript and Display postscript were developed first, but describing them as "an older technology" has an implication of it being a less advanced system, where really it is still the more advanced one.
According to
The PDF Reference, (labeled page 21 in the document, but the 41 page to the PDF renderer) "To simplifiy the processing of content streams, PDF does not include common programming language features such as procedures, variables, and control constructs." The imaging model of Postscript, Display Postscript, and PDF are the same, but PDF's limited set of operators don't return values. Instead of procedures, PDF has parameterized streams (similar to macros)
On the plus side, the rigidly defined file format allows PDF renderers to jump to any section of the document without rendering previous ones, and allows documents to be statically checked for validity. (Postscript documents need to be executed before you can actually know whether they are valid or not.)
Ghostscript does have PDF encoding and decoding capabilities, making use of the strong similarities between the two systems.
When Apple bought Next in 1996, Next not only had NextStep (Mach+BSD+OPENSTEP+DPS, the system OS X was based on) running on Intel hardware, but also had OPENSTEP running on Win32. This was an important part Apple's original strategy. OPENSTEP was known for being a development environment that allowed for rapid application development and giving away the OPENSTEP DLLs for Win32 royalty free allowed developers better tools that traditional win32 development, and Apple as a side effect got products developed to their API.
It was the big name Mac/Windows cross platform developers, Adobe, Microsoft, and Macromedia that put a stop to this plan. They already had their own cross platform tools already in place. If they had to port to yellowbox (as OPENSTEP was known in its initial incarnation at Apple.) just to keep selling apps for the mac, they would have just as well drop mac support entirely.
Apple conceded to their major app developers, and developed Carbon, as API similar to the classic MacOS. Since yellowbox couldn't coax windows developers to write cross platform Windows/Mac applications, then its drawbacks (the potential decrease in Macintosh computer sales) outweighed its advantages (that large amount of available software could increase Macintosh computer sales.)
Re:Classes and APIs more important than language
on
What is .NET?
·
· Score: 2, Informative
That is because the FSF started the Guile project so that people would stop using TCL as an extension language. The basis of the Guile project was RMS's declaration Why you should not use Tcl When people stopped trying to use Tcl as an extention language to GNU code, the Guile developers were less motivated to create a system that could understand Tcl syntax.
Take a look at the format of the DISPLAY environment variable, and notice what the various parts do. (assuming a machine with TCP, X can use other transports, and the DISPLAY variable is different)
hostname:0.0
Where I put "hostname", is of course the name of hte machine. The next section, after the colon, X calls the "display", and this refers to a complete set of input and output devices for a single user. The last section, after the dot is called a "screen", which is a bitmapped output device for X (basically another monitor.)
Things like VNC and ssh's X forwarding set themselves up as additional displays (screen, keyboard, and mouse combos) and proxy the X events that they receive to the machine at the other end of the network link.
So X itself is designed for multiple users per machine. (think about it, a lot of the original work on X was done at DEC. They had a motivation to support big multiuser machines.) The issue here is whether linux's USB support allows you to read from a single keyboard on the USB bus and ignore key events from other keyboards.
I'd say that when Ambrosia switched from fully functional shareware to time limited demos, they knew that they were losing some sales due to their stifling the referral marketing. As a business, they decided the potential gain (the five times the registrations that they read about) was preferable to the potential downfall (they lower distribution of their product.)
So knowing they were losing a bit of distribution for a better ratio of registration, Ambrosia decided to build their current system anyway. Its their business, and its not for you to crack it and try to help them in their old business model. If you asked them about this scenario, they would probably say "Thanks, but no thanks."
You mean that people choose convenience (in the bottled water case, a resealable container and no cups to wash out) over price.
Before the bottled water craze, the soft drink marketing departments started to see an odd dichotomy. People were either drinking carbonated beverages for convenience or water for health. And the country as a whole was moving towards a more healthy lifestyle. Bottled water gave those carbonated beverage drinkers the same convenience they are used to, at the same price. (but as implied in another comment, harmful in the end. Most of the bottles are thrown away rather than recycled, and distribution by truck is energy inefficient.)
How this compares to shareware, I don't know. To me, shareware seems like the more convenient option. (download to preview, pay when you are sure it is what you want.) and bottled water seems like the more convenient option (transportable and disposable.)
I think you are going to give me another hint on the analogy you want me to take from this.
That isn't quite true. They did have most of the apps that came from the X consortium's base distribution. Also they had what was at their time the neatest X app. One that would intercept all keyboard and screen writing calls of any DOS app and turn them into X events.
This isn't like VNC's remote computing where you get a view of the remote machine's screen. This was turning a program into a X client, each invocation being displayed on any arbitrary machine on the network.
Whether OS X seems like Unix or not depends on you
on
How Unix-like is MacOS X?
·
· Score: 5, Informative
Whether you call it Unix at all depends on your definition. Depending
on whether you look at OSX from a kernel perspective, as a development
platform, a unix user, or a unix administrator, it can vary between
being a "true unix" to something very foreign.
It most looks like unix if look at a system call interface (aka
section 2 of the man pages. Things like open, read, write, close,
fork, and exec). The user commands (section 1 of the man pages. Things
like ls,cp, and rm) exist but all of/bin,/sbin, and/usr are
entirely hidden from the GUI. For actual user commands, they are in
some ways rather spartan (traditional BSD versions, not all-singing,
all-dancing GNU versions.) but there are some rather interesting
additions (emacs, tcsh, pico, gcc, autoconf, and gnu tar.)
Standard Unix system libraries (section 3 of the man pages
fopen,fread,printf,system,and popen) exist as a "non-preferred"
interface. The command line utilities are built against them, but
building an arbitrary tarball developed under linux might show some
compatiblity quirks. (those same quirks might exist trying to port to
FreeBSD) Most of the file and process oriented tasks can be done in
the OS X specific libraries with an API entirely unlike the POSIX ones
in libc. (This isn't anything new really, these OS X libraries are the
updated versions of what came with the first NextStations in 1987.)
Shared libraries are somewhat different than what probably currently
exists in FreeBSD. I bet it started because NeXT implemented shared
libraries before the became standard in BSD, but they need to continue
their own system because it hooks into the object oriented IPC
framework that is much of what the makes the system interesting.
From a system administrators standpoint (I guess to keep my analogies,
section 4 (device files) and section 5 (configuration files)) things
are radically different./etc/passwd is essentially a stub. There is
no/etc/inittab. There are few useful things in/usr/lib,/usr/share,
/var, or/etc, but/Library and/System/Library are full of goodies
(like/System/Library/Perl and/System/Library/OpenSSL). There is no
/home, instead there is/Users (which through some automount magic
merges/Network/Users with the local/Users) Again, this system is
inherited from NeXT.
As a user, its a modern mouse and windows type of system. Its slightly
more interapplication oriented, less monolithic application oriented.
Like my friends who used NeXT systems in the past, there seem to be
two ways to deal with the system peculiarities. The first is to assume
that the system is a very stripped down Unix system, ignore whats in
/Library and/System/Library and build your own
/usr/local/{bin,lib,share}. The other way is to buy into its
weirdness.
Sometimes form painting software helps lay out controls better, but most tools tend to skew the programming logic in certain ways. Some tools make it hard to create an array of data structures that contain GUI components.
Using CLI tools to build GUI interfaces can be hard, but it is possible to make an interface that looks exactly like a CLI one. On the other hand, if the code generation of the GUI form building tool doesn't create code the way you have done it yourself, its impossible to fix.
Sometimes the best thing that you can do is to use the GUI tools to lay out the interface, check the placement of the components and build it again from scratch.
Don't worry about it. If the US Copyright office only got 30 comments about the DMCA when Slashdot said "Tell the Copyright Office what you think of DMCA", no one is going to go through the effort of contacting Trident. (Of course on the other hand, the "Please don't piss off Trident is going to set off some antisocial dimwit.)
But for the most part, Slashdot readers are going to be much happier bickering amongst themselves.
The OmniWeb browser for OS X has that capability. The javascript preferences has an item "scripts are allowed to open new windows" with the choices of "always", "never", and "only in response to a link being clicked"
I wouldn't describe Nisus as an early mac word processor. By the time it came out, not only had the standbys at the time MacWrite and Word gotten themselves well established, but some of the failures like WriteNow and FullWrite and already come and gone. Nisus probably came out about the time that WordPerfect joined into the fray.
For years, the makers of Nisus were known for their programmers text editor QUED/M a programmer's text editor. It was only after building word processing features onto the editor did they come up with Nisus. Hmm according to About Nisus Software Nisus came out in 1989. I guess it might qualify as the early years of the Macintosh by now, but besides ClarisWorks/AppleWorks, I can't think of any other word processors that came after Nisus.
The blackboard is being constructed in Charlottesville Virginia. The writer of the article, Ellen Goodman, is a columnist for the Boston Globe.
Re:Language being created before my eyes
on
Apocalypse 2
·
· Score: 1
Its a shame that google doesn't have the Usenet archives for 1993-1994 comp.lang.perl (not comp.lang.perl.*) published yet. Larry's devopment was very similar. As he got new ideas, he'd post them. As people came up with suggestions, they'd post them and Larry would point out the advantages and disadvantages of them.
Of course, comp.lang.perl was an entirely different environment back then.
The user that installs the RPM has to be able to write to the installation directories and to the RPM db. With the --relocate switch, you can set the directories that most applications write to. With the --dbpath switch you can control the RPM database to write to.
Maybe the wording wasn't quite right, but Mosaic revolutionized the way graphics where used on the web. It was the first to implent inline images with the tag. Previous to that a web page could contain text or link to a single image file.
WorldWideWeb.app wasn't much more than lynx with a helper app set for image viewing.
Slashdot Mirror
I attended a talk earlier this year given by Andy McKay from Activestate describing their use of Zope on activestate.com. Basically for one portion of their site they develop all their software on Zope on their development server, export it all to flat files and push it to their production side.
So just because a CMS wants to be a web server, that doesn't mean it has to the a production web server.
Souped up isn't quite accurate. I'd call it relabled. The only difference between nCompass 4.0 and MS-CMS 2001 was the removal of the Oracle DBMS interface.
.NET strategy. MS CMS supports XML natively.")
Some of Microsoft's marketing blurbs will try to confuse the issue. (with statements like "XML is an important part of Microsoft's
To reach the current state of GUI file managers, they (the same they that you were referring to.) that basing the system on recalling visual cues over remembering commands gave certain advantages to a certain group of users. I'd consider this an experiment in whether a spatial cues help or hinder the users navigation of the system.
By the time this research manifests itself as a marketable product, it might not be a 3D browser any more. It might just be that some facet of this app makes someone figure out how to create a single paned view that can show disparate parts of the file system hierarchy.
This reminds me a bit about an argument I had with a friend of mine about Lingua::Romana::Perligata. He couldn't see the package as anything but a waste of time, programming in a dead natural language. The point that I tried to make about the library isn't simply to write programs in latin. It could be viewed as an experiment in determining whether programming languages are required to be positionally dependent. If the results from Lingua::Romana::Perligata showed that there were significant advantages from determining syntax from inflection rather than position, a new syntax (not based on dead languages) could be developed by someone creating a commercial product.
The "fly over the documents" metaphor has been tried before. In some ways it was the precursor to the office metaphor used for the Macintosh (As noted in the Son of Dataland section of the paper Inventing the Lisa User Interface
It might not be a matter of not caring, but some people are perfectly aware of the effects of allowing companies to collect profiling data and still have differing opinions on its merits.
I know someone who nearly will go out of their way to collect any sort of "preferred customer" card, rebate, or other sort of marketing/profiling collection scheme. Their view is "If companies are going to pay me money to cater their products to what I'm most likely to purchase. I'll tell them anything they want to know."
According to The PDF Reference, (labeled page 21 in the document, but the 41 page to the PDF renderer) "To simplifiy the processing of content streams, PDF does not include common programming language features such as procedures, variables, and control constructs." The imaging model of Postscript, Display Postscript, and PDF are the same, but PDF's limited set of operators don't return values. Instead of procedures, PDF has parameterized streams (similar to macros)
On the plus side, the rigidly defined file format allows PDF renderers to jump to any section of the document without rendering previous ones, and allows documents to be statically checked for validity. (Postscript documents need to be executed before you can actually know whether they are valid or not.)
Ghostscript does have PDF encoding and decoding capabilities, making use of the strong similarities between the two systems.
When Apple bought Next in 1996, Next not only had NextStep (Mach+BSD+OPENSTEP+DPS, the system OS X was based on) running on Intel hardware, but also had OPENSTEP running on Win32. This was an important part Apple's original strategy. OPENSTEP was known for being a development environment that allowed for rapid application development and giving away the OPENSTEP DLLs for Win32 royalty free allowed developers better tools that traditional win32 development, and Apple as a side effect got products developed to their API.
It was the big name Mac/Windows cross platform developers, Adobe, Microsoft, and Macromedia that put a stop to this plan. They already had their own cross platform tools already in place. If they had to port to yellowbox (as OPENSTEP was known in its initial incarnation at Apple.) just to keep selling apps for the mac, they would have just as well drop mac support entirely.
Apple conceded to their major app developers, and developed Carbon, as API similar to the classic MacOS. Since yellowbox couldn't coax windows developers to write cross platform Windows/Mac applications, then its drawbacks (the potential decrease in Macintosh computer sales) outweighed its advantages (that large amount of available software could increase Macintosh computer sales.)
That is because the FSF started the Guile project so that people would stop using TCL as an extension language. The basis of the Guile project was RMS's declaration Why you should not use Tcl When people stopped trying to use Tcl as an extention language to GNU code, the Guile developers were less motivated to create a system that could understand Tcl syntax.
Take a look at the format of the DISPLAY environment variable, and notice what the various parts do. (assuming a machine with TCP, X can use other transports, and the DISPLAY variable is different)
hostname:0.0
Where I put "hostname", is of course the name of hte machine. The next section, after the colon, X calls the "display", and this refers to a complete set of input and output devices for a single user. The last section, after the dot is called a "screen", which is a bitmapped output device for X (basically another monitor.)
Things like VNC and ssh's X forwarding set themselves up as additional displays (screen, keyboard, and mouse combos) and proxy the X events that they receive to the machine at the other end of the network link.
So X itself is designed for multiple users per machine. (think about it, a lot of the original work on X was done at DEC. They had a motivation to support big multiuser machines.) The issue here is whether linux's USB support allows you to read from a single keyboard on the USB bus and ignore key events from other keyboards.
I'd say that when Ambrosia switched from fully functional shareware to time limited demos, they knew that they were losing some sales due to their stifling the referral marketing. As a business, they decided the potential gain (the five times the registrations that they read about) was preferable to the potential downfall (they lower distribution of their product.)
So knowing they were losing a bit of distribution for a better ratio of registration, Ambrosia decided to build their current system anyway. Its their business, and its not for you to crack it and try to help them in their old business model. If you asked them about this scenario, they would probably say "Thanks, but no thanks."
You mean that people choose convenience (in the bottled water case, a resealable container and no cups to wash out) over price.
Before the bottled water craze, the soft drink marketing departments started to see an odd dichotomy. People were either drinking carbonated beverages for convenience or water for health. And the country as a whole was moving towards a more healthy lifestyle. Bottled water gave those carbonated beverage drinkers the same convenience they are used to, at the same price. (but as implied in another comment, harmful in the end. Most of the bottles are thrown away rather than recycled, and distribution by truck is energy inefficient.)
How this compares to shareware, I don't know. To me, shareware seems like the more convenient option. (download to preview, pay when you are sure it is what you want.) and bottled water seems like the more convenient option (transportable and disposable.)
I think you are going to give me another hint on the analogy you want me to take from this.
That isn't quite true. They did have most of the apps that came from the X consortium's base distribution. Also they had what was at their time the neatest X app. One that would intercept all keyboard and screen writing calls of any DOS app and turn them into X events.
This isn't like VNC's remote computing where you get a view of the remote machine's screen. This was turning a program into a X client, each invocation being displayed on any arbitrary machine on the network.
Whether you call it Unix at all depends on your definition. Depending
/bin, /sbin, and /usr are
/etc/passwd is essentially a stub. There is
/etc/inittab. There are few useful things in /usr/lib, /usr/share,
/etc, but /Library and /System/Library are full of goodies
/System/Library/Perl and /System/Library/OpenSSL). There is no
/Users (which through some automount magic
/Network/Users with the local /Users) Again, this system is
/System/Library and build your own
on whether you look at OSX from a kernel perspective, as a development
platform, a unix user, or a unix administrator, it can vary between
being a "true unix" to something very foreign.
It most looks like unix if look at a system call interface (aka
section 2 of the man pages. Things like open, read, write, close,
fork, and exec). The user commands (section 1 of the man pages. Things
like ls,cp, and rm) exist but all of
entirely hidden from the GUI. For actual user commands, they are in
some ways rather spartan (traditional BSD versions, not all-singing,
all-dancing GNU versions.) but there are some rather interesting
additions (emacs, tcsh, pico, gcc, autoconf, and gnu tar.)
Standard Unix system libraries (section 3 of the man pages
fopen,fread,printf,system,and popen) exist as a "non-preferred"
interface. The command line utilities are built against them, but
building an arbitrary tarball developed under linux might show some
compatiblity quirks. (those same quirks might exist trying to port to
FreeBSD) Most of the file and process oriented tasks can be done in
the OS X specific libraries with an API entirely unlike the POSIX ones
in libc. (This isn't anything new really, these OS X libraries are the
updated versions of what came with the first NextStations in 1987.)
Shared libraries are somewhat different than what probably currently
exists in FreeBSD. I bet it started because NeXT implemented shared
libraries before the became standard in BSD, but they need to continue
their own system because it hooks into the object oriented IPC
framework that is much of what the makes the system interesting.
From a system administrators standpoint (I guess to keep my analogies,
section 4 (device files) and section 5 (configuration files)) things
are radically different.
no
/var, or
(like
/home, instead there is
merges
inherited from NeXT.
As a user, its a modern mouse and windows type of system. Its slightly
more interapplication oriented, less monolithic application oriented.
Like my friends who used NeXT systems in the past, there seem to be
two ways to deal with the system peculiarities. The first is to assume
that the system is a very stripped down Unix system, ignore whats in
/Library and
/usr/local/{bin,lib,share}. The other way is to buy into its
weirdness.
Many people do use the term Linux, but where do you see it ever used in a context other than a Unix-like kernel published by Linus Torvalds?
Well, if you can get it off of the disk, the source code to FORMAL is available.
Sometimes form painting software helps lay out controls better, but most tools tend to skew the programming logic in certain ways. Some tools make it hard to create an array of data structures that contain GUI components.
Using CLI tools to build GUI interfaces can be hard, but it is possible to make an interface that looks exactly like a CLI one. On the other hand, if the code generation of the GUI form building tool doesn't create code the way you have done it yourself, its impossible to fix.
Sometimes the best thing that you can do is to use the GUI tools to lay out the interface, check the placement of the components and build it again from scratch.
Don't worry about it. If the US Copyright office only got 30 comments about the DMCA when Slashdot said "Tell the Copyright Office what you think of DMCA", no one is going to go through the effort of contacting Trident. (Of course on the other hand, the "Please don't piss off Trident is going to set off some antisocial dimwit.)
But for the most part, Slashdot readers are going to be much happier bickering amongst themselves.
The OmniWeb browser for OS X has that capability. The javascript preferences has an item "scripts are allowed to open new windows" with the choices of "always", "never", and "only in response to a link being clicked"
For years, the makers of Nisus were known for their programmers text editor QUED/M a programmer's text editor. It was only after building word processing features onto the editor did they come up with Nisus. Hmm according to About Nisus Software Nisus came out in 1989. I guess it might qualify as the early years of the Macintosh by now, but besides ClarisWorks/AppleWorks, I can't think of any other word processors that came after Nisus.
The blackboard is being constructed in Charlottesville Virginia. The writer of the article, Ellen Goodman, is a columnist for the Boston Globe.
Of course, comp.lang.perl was an entirely different environment back then.
The user that installs the RPM has to be able to write to the installation directories and to the RPM db. With the --relocate switch, you can set the directories that most applications write to. With the --dbpath switch you can control the RPM database to write to.
WorldWideWeb.app wasn't much more than lynx with a helper app set for image viewing.