Some of the points of this article - relating to the AT&T debacle - are the approach of a brainwashed Redmondite... "We have standardized telephone jacks, so therefore we need a standardized operating system".
That is the sort of analogy that people make, and it's an extremely bad one. Telephone jacks are what connect multiple phones together, and a telephone is what a user uses.
A better analogy would be, "We have standardised telephones, so we need a standardised operating system". Except, that analogy is based on a falsehood--we don't have standardised telephones. Some of us have red telephones, some of us have blue ones, there are ones that you strap to your head, there are corded and cordless ones, there are cellular telephones, there are telephones with littel caller-ID displays built right into them, there are ones with volume-boosting buttons, there are ones with key-pads for people with poo vision, there are autodialers, there pieces of software that act as telephones, and there are... many types of telephones.
The way that the telephones interoperate, however, is standardised. So, let's use that as the basis of our analogy:
"We have standardised interoperation mechanisms for our telephones, so we need standardised interoperation mechanisms for our operating systems."
Protocols and file-formats.
If my computer can communicate with everyone else's, because they all uses common data-interchange formats, then for what reasons would I--should I--care about what Joe-down-the-hall's operating environment looks like to him?
Regardless of what it looks like to him, it's going to look the same to me, so it might as well look like whatever make Joe-down-the-hall most comfortable.
In what way is the BSD-license (too) restrictive to you?
I don't think that that was the point. Think "meta". The BSD licenses allow someone to relicense with a very restrictive license. While the BSD-licensers don't place the restrictions, they obviously don't have a problem with them;)
`I wouldn't kill someone, but that's not to say that killing is wrong, or that I have a problem with it....'
No, that's potentially a very inflammatory example....
Yep--if you want fuzzy text, you need to use Mac OS X.
`virtual memory' != `swap space'
on
Is UNIX An OS?
·
· Score: 1
`swap space' is space that is used to swap processes out to. You can have (and use) swap space without having a virtual-memory system--you can swap tasks out of memory and back in, so you can run lots of tasks, for which the total, aggregate memory usage is greater than your amount of physical RAM, but you cannot run one processes that, itself, requires more RAM than you physically have.
If a modified version of the licensed code is required to be a "library" (which is defined in section 0 in the intuitive way), then how can you create an application, and license it under the LGPL in such a way that anyone can modify and redistribute it in application form without violating the license?
As DeadSea wrote in response to another article, it's generally better to implement libraries as libraries than nonmodular applications. Implement the functionality of your application as a library, or a set of libraries, and a stubby little main routine, and then you won't really need to care about whether the LGPL can be applied to things that aren't libraries.
That's the point that RMS makes in his article, `The GNU Project'--software was free and open, and then people made it proprietary and closed (or, at least, he was accustomed to being part of a community that shared the software that it produced, and then that all apparently died).
... Mac OS X will eventually displace Linux and *BSD and GNU and other Free Software that chooses to duplicate rather than evolve....
As we can see, the Free Software groups just attempt to reimplement what's been done in commercial software.
Have you read anything about the HURD?
GNU really isn't just a reimplementation of any OS that I've ever seen--it may be POSIX-compatible, but it sure as hell isn't unix.
All X applications still have to formulate their drawing commands into X drawing commands and pipe them through the high-speed local socket. The local X server then has to read the command from the input, decode and interpret them, and then call its API calls to draw them.
Actually, no, that doesn't need to happen. What happens is this:
The application code uses the API to put a call to an X11 library's code, and the library takes implementation-specific steps to get carry out the application's drawing requests.
All of the overhead that you've mentioned is really an implementation issue; there's no reason that an X library can't be written that will forgo X11-protocol-usage and just draw to the screen.
There was a TechNetCast interview with Thomas Bushnell (lead HURD architect), last month--
http://www.technetcast.com/tnc_play_stream.html? stream_id=381
The only people who are even working on any of it are the debian people and Stallman himself and I don't see too much work going on in that area.
I'll be getting another PC, shortly, at which point the number of HURD developers will probably be increased by 1....
So far, the only thing that I've been able to do that's close to useful is read the documentation and mail from the lists; the documentation is apparently quite out of date, though. The problem that people cite with regard to, say, Mozilla of `it's difficult to understand and find something to contribute' is present in the HURD, and it looks really severe.
There is some progress on cool parts of the HURD being made, but--oiy--it does look slow.
I'm sure that it will eventually be developed into something more usable/useful, and, once it hits that point, its development speed will probably increase.
Where will the HURD be by 2003? Hm. Good question....
The new string it retrieves from the database should contain the same specifiers in the same order, or gettext should return the original string. Isn't this better than modifying the tons of source code that use the localization info?
In a word, `no'.
That the translated version of a string is going to contain the same number of any character is a bad assumption.
That the string returned by gettext is always going to be passed to *printf is also a bad assumption (the *puts functions still exist, you know...).
It'd probably be better to modify the operation of *printf, so that excess format-characters are not evaluated (ie: the second "%d" in `printf("%d%d", 2)'), but that's probably not going to happen;)
I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ?
Python doesn't have arrays like Perl has (which contain scalars)--it has lists (which contain anything)--nor does Python use opaque references, as Perl does.
But, if you want to get at a list that's referenced by a dictionary (associative array), you'd use:
Most of us bitched when Apple sued e-Machines.
Most of us bemoaned the recent tabbed-dialogue-patent suit.
Most of us were disgusted by Apple's response to the Mac-OS-X-like themes for non-Apple systems.
And, now, we're asked what we think about Hobbes' duplication of Linux.com's interface?
With a polygon (or other surface type) based model you still get a smooth image.
That's actually not quite right; polygon meshes begin to look very faceted if your model isn't composed of small-enough polygons, or if you get close enough. One polygon is smooth, but a whole bunch of them, put together at the edges, is not smooth. The problem with polygon meshes is largely `solved' by doing surface-normal-perturbations and such, so that, for the mesh surfaces that are more perpendicular to the viewer's line of sight, everything looks smooth. This doesn't help the edges, though.
Splines guarantee smooth surfaces of any form at any resolution, but the equations become increasingly complex as the numbers of of control points increase (the orders of the functions go up). To get around this, you can break a surface up into a number of patches, and keep each patch relatively simple (16 points, and a quadratic function, for example).
It can be tough to work with things like Beziers, though, because increasing complexity in one area of the surface can lead to increased complexity in some other, `completely unrealted', area. Of course, Beziers are also more expensive to calculate than triangles....
Subdivision surfaces are nice--you basically create a triangle mesh and then smooth out all of the corners (really smooth them, not just play with the way that light reflects off of them). Subdivision surfaces give you the ease of use of polygon meshes, and the high quality of spline patches.
Hm. I guess that I'd like to see subdivision accelerators:)
Slashdot Mirror
Some of the points of this article - relating to the AT&T debacle - are the approach of a brainwashed Redmondite... "We have standardized telephone jacks, so therefore we need a standardized operating system".
That is the sort of analogy that people make, and it's an extremely bad one. Telephone jacks are what connect multiple phones together, and a telephone is what a user uses.
A better analogy would be, "We have standardised telephones, so we need a standardised operating system". Except, that analogy is based on a falsehood--we don't have standardised telephones. Some of us have red telephones, some of us have blue ones, there are ones that you strap to your head, there are corded and cordless ones, there are cellular telephones, there are telephones with littel caller-ID displays built right into them, there are ones with volume-boosting buttons, there are ones with key-pads for people with poo vision, there are autodialers, there pieces of software that act as telephones, and there are... many types of telephones.
The way that the telephones interoperate, however, is standardised. So, let's use that as the basis of our analogy:
"We have standardised interoperation mechanisms for our telephones, so we need standardised interoperation mechanisms for our operating systems."
Protocols and file-formats.
If my computer can communicate with everyone else's, because they all uses common data-interchange formats, then for what reasons would I--should I--care about what Joe-down-the-hall's operating environment looks like to him?
Regardless of what it looks like to him, it's going to look the same to me, so it might as well look like whatever make Joe-down-the-hall most comfortable.
In what way is the BSD-license (too) restrictive to you?
I don't think that that was the point. Think "meta". The BSD licenses allow someone to relicense with a very restrictive license. While the BSD-licensers don't place the restrictions, they obviously don't have a problem with them;)
`I wouldn't kill someone, but that's not to say that killing is wrong, or that I have a problem with it....'
No, that's potentially a very inflammatory example....
Yes, the program that she was using was a real program available for real unix systems--you can download it from SGI's web-site.
Are you sure that it's not Sawfish?
Yep--if you want fuzzy text, you need to use Mac OS X.
`swap space' is space that is used to swap processes out to. You can have (and use) swap space without having a virtual-memory system--you can swap tasks out of memory and back in, so you can run lots of tasks, for which the total, aggregate memory usage is greater than your amount of physical RAM, but you cannot run one processes that, itself, requires more RAM than you physically have.
See the entry for `virtual memory' in the FOLDOC.
If a modified version of the licensed code is required to be a "library" (which is defined in section 0 in the intuitive way), then how can you create an application, and license it under the LGPL in such a way that anyone can modify and redistribute it in application form without violating the license?
As DeadSea wrote in response to another article, it's generally better to implement libraries as libraries than nonmodular applications. Implement the functionality of your application as a library, or a set of libraries, and a stubby little main routine, and then you won't really need to care about whether the LGPL can be applied to things that aren't libraries.
"HURD" stands for "HIRD of Unix Replacement Daemons"
"HIRD" stands for "HURD of Interfaces Representing Depth"
BSD is democracy
Linux is communism
What kind of economy is BSD?
What kind of government is Linux?
That's the point that RMS makes in his article, `The GNU Project'--software was free and open, and then people made it proprietary and closed (or, at least, he was accustomed to being part of a community that shared the software that it produced, and then that all apparently died).
Open a version-controlled file in GNU emacs, hit C-x C-q to edit it, edit it, then hit C-x C-q again to check it in.
How about something from Edmund Scientifics?
They have robot kits, Magic Rocks and other crystal-growing kits, night-vision goggles, lasers, and all sorts of great tools and toys.
Outlook syncs to my mobile phone, point me to another program that does that, and I'll use it.
Hm.
Point me to some specs, and I'll write you one:)
... Mac OS X will eventually displace Linux and *BSD and GNU and other Free Software that chooses to duplicate rather than evolve....
As we can see, the Free Software groups just attempt to reimplement what's been done in commercial software.
Have you read anything about the HURD?
GNU really isn't just a reimplementation of any OS that I've ever seen--it may be POSIX-compatible, but it sure as hell isn't unix.
All X applications still have to formulate their drawing commands into X drawing commands and pipe them through the high-speed local socket. The local X server then has to read the command from the input, decode and interpret them, and then call its API calls to draw them.
Actually, no, that doesn't need to happen. What happens is this:
The application code uses the API to put a call to an X11 library's code, and the library takes implementation-specific steps to get carry out the application's drawing requests.
All of the overhead that you've mentioned is really an implementation issue; there's no reason that an X library can't be written that will forgo X11-protocol-usage and just draw to the screen.
... the desperate need to prove to them they are wrong and broudcast it loudly probably represents a desire to be proven wrong.
Does this hold true for everyone, or just Atheists? What about Christians who do this?
There was a TechNetCast interview with Thomas Bushnell (lead HURD architect), last month--? stream_id=381
http://www.technetcast.com/tnc_play_stream.html
The only people who are even working on any of it are the debian people and Stallman himself and I don't see too much work going on in that area.
I'll be getting another PC, shortly, at which point the number of HURD developers will probably be increased by 1....
So far, the only thing that I've been able to do that's close to useful is read the documentation and mail from the lists; the documentation is apparently quite out of date, though. The problem that people cite with regard to, say, Mozilla of `it's difficult to understand and find something to contribute' is present in the HURD, and it looks really severe.
There is some progress on cool parts of the HURD being made, but--oiy--it does look slow.
I'm sure that it will eventually be developed into something more usable/useful, and, once it hits that point, its development speed will probably increase.
Where will the HURD be by 2003? Hm. Good question....
I've seen that Mac OS X uses "/" as a separator character in paths (rather than ":")--does anyone know about other small unixisms being put in?
What about the EOL character? Does Mac OS X use newline, or does it still use carriage-return?
Does anyone here know?
Finally, a REAL UI with a BSD based system.
'too bad that it's proprietary.
Ohwell. HURD will end up beating the pants off of unix, anyway, and it's free:)
The new string it retrieves from the database should contain the same specifiers in the same order, or gettext should return the original string. Isn't this better than modifying the tons of source code that use the localization info?
In a word, `no'.
That the translated version of a string is going to contain the same number of any character is a bad assumption.
That the string returned by gettext is always going to be passed to *printf is also a bad assumption (the *puts functions still exist, you know...).
It'd probably be better to modify the operation of *printf, so that excess format-characters are not evaluated (ie: the second "%d" in `printf("%d%d", 2)'), but that's probably not going to happen;)
#1: You convert Python into an OS so that it can have all of the system resources to itself and your Python programs can run faster
#2: instead of using `ls', in unix, you use:
python -c "map(lambda x: __import__('sys').stdout.write(x+'\n'), __import__('os').listdir('.'))"
I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ?
Python doesn't have arrays like Perl has (which contain scalars)--it has lists (which contain anything)--nor does Python use opaque references, as Perl does.
But, if you want to get at a list that's referenced by a dictionary (associative array), you'd use:
foo['bar']
Most of us bitched when Apple sued e-Machines.
Most of us bemoaned the recent tabbed-dialogue-patent suit.
Most of us were disgusted by Apple's response to the Mac-OS-X-like themes for non-Apple systems.
And, now, we're asked what we think about Hobbes' duplication of Linux.com's interface?
With a polygon (or other surface type) based model you still get a smooth image.
That's actually not quite right; polygon meshes begin to look very faceted if your model isn't composed of small-enough polygons, or if you get close enough. One polygon is smooth, but a whole bunch of them, put together at the edges, is not smooth. The problem with polygon meshes is largely `solved' by doing surface-normal-perturbations and such, so that, for the mesh surfaces that are more perpendicular to the viewer's line of sight, everything looks smooth. This doesn't help the edges, though.
Splines guarantee smooth surfaces of any form at any resolution, but the equations become increasingly complex as the numbers of of control points increase (the orders of the functions go up). To get around this, you can break a surface up into a number of patches, and keep each patch relatively simple (16 points, and a quadratic function, for example).
It can be tough to work with things like Beziers, though, because increasing complexity in one area of the surface can lead to increased complexity in some other, `completely unrealted', area. Of course, Beziers are also more expensive to calculate than triangles....
Subdivision surfaces are nice--you basically create a triangle mesh and then smooth out all of the corners (really smooth them, not just play with the way that light reflects off of them). Subdivision surfaces give you the ease of use of polygon meshes, and the high quality of spline patches.
Hm. I guess that I'd like to see subdivision accelerators:)