Problem is, there's no obvious `standard' way of doing so, aside from writing it. What is required is the integration of various tools from document authouring through to software production.
The only standard way of writing descriptive text together with source code is ASCII. Javadoc does too little, as do may other `solutions' for this. A better approach would be to include documentation production into the systems that Source Carpentry are after (so that design/analysis/in-code-documentation are expected parts of a program) John
Those are POSIX 'capabilities' which are not the same thing as 'capabilities' as in EROS et al.
As reiterated by capability proponents, they are not the same thing
And in case you were wondering, the name clash was POSIX' fault. --- the idea of capabilities as in EROS/KEYKOS/SPEEDOS/etc. predates POSIX (I think), let alone POSIX 'capabilities'
In particular, note the principal of least privaledge -- just because a program needs one small aspect of root's privaledges, doesn't mean it necessarily needs to be given all of them -- in practice, this gets rid of the root account per se., which is never bad where security is concerned.
The quote mentions location transparency, i.e. network transparency, not alpha-channel transparency that is being discussed. Yes, Berlin does do alpha, though.
XFree86 4.0 is here. Don't expect Berlin this side of a few total rewrites -- it's (justifiably) experimental and will most likely stay that way until the developers are happy with it.
The processors alone don't matter that much. How data is piped from one processor/memory/cluster/etc. to another is what matters -- and then performance will depend heavily on what sort of problems are run on it. John
Bandwidth is not intellectual property, and certainly isn't covered by copyright laws.
Slade's bandwidth deal is with his access provider, and any use of it which doesn't contranvene computer misuse acts is legitimate. Importantly, IT IS NOT SUBJECT TO INTELLECTUAL PROPERTY LICENSING -- IT IS THE COPYRIGHTABLE SOFTWARE THAT IS SUBJECT TO LICENSE, AND THAT LICENSE IS THE GPL
Gees, people seem to think that anything may be declared intellectual property, copyright, etc. and licensed.
To anybody who thinks I am saying that all bandwidth is free, I am not. Just that it isn't subject to the same laws as software. In any case, slade is not permitted to place the requirement that the downloader renounce his rights under GPL, since that violates the GPL agreement that HE has agreed to for HIS copy of the software (note that this is independant of any downloaded copies).
One important point which should be made about the stampede optimisations, is that they tend to make for an unstable distribution -- I had rather more random segfaults on a K6 then I did under RH6 (which replaced it).
The stampede project should really give two things important weight in the system
The system should be very 'recompile-centric', i.e. it should be organised such that you can stick the source onto your new machine, set the basic target architecture in some core config file, and then rerun gcc for your system.
Such an approach would make it simple enough to put '-march=k6 -O6 --everything' and then recompile and repackage your entire system (though I think that this places too many demands on the build system --- I'll stop dreaming now) John
forget files and symlinks -- the configuration system doesn't need the complexity of the entire filesyste, while at the same time it does require extra facilities to be managed efficiently (e.g. how are users' changes stored, what about group configurations (so you have a system default, a group inherits and modifies it, and then users from a particular workgroup may inherit from that, picking up any alterations AS THEY ARE MADE).
The long haul solution is to virtualise the entire user-visible heirachiy, and present THAT in the/usr filesystem (which would then look different dependant upon which user was logged in -- i.e. user filesystem -- with system stuff in/sys for example)
The point that must be reiterated over and over again until understood is that the
The Current way of doing things is not sufficent for an integrated approach to package management. and further Hacking it will NOT help in the long run -- careful design is required
In the long run, EVERYTHING must be questioned, from languages to build trees to user-visible filesystem (and what such terms mean).
Many people quote the 'Unix approach' as begin 'do it once, do it right'. That is not plausible unless you are prepared to throw away everything that isn't right in persuit of 'doing it right'. Eventually, incremential changes must be binned in favour of a complete redesign, followed by a complete rewrite. (people should take note that a total rewrite alone doesn't work -- you just reinvent what you had before, with a few changes)
where all sources go into the source subdirectory, all config/build related stuff into the build subdirectory and the final package files go into e.g. export/i686-pc-linux-gnu/Locations export/i686-pc-linux-gnu/bin/ export/i686-pc-linux-gnu/lib/ export/i686-pc-linux-gnu/include/ export/i686-pc-linux-gnu/share/ which can then be installed from.
short, simple, and would make life a lot easier, especially with multiple builds (i.e. debug, normal, fast etc.)
Please explain how dependencies could be added to stow without much difficulty? Stow has no procedure for handling multiple instances of the same file in different packages, let alone ensuring that a given package gets the versions of the libraries that it needs (different packages require different versions of libpng, for example).
p.s. stow requires perl, which requires libc, which would get killed by a rm -rf/lib. Also, when make install'ing a program, should the program look directly inside the stow tree for its files, or inside the/usr/local heirarhcy for example, where the files are installed? The former makes things such as GNUstep get rather nasty, since things aren't relative to GNUSTEP_SYSTEM_ROOT, and the latter makes organisiation difficult, since the file->package relations break down.
In short, more flexible 'framework/build-tree' organisation methods are required for things such as KDE, GNOME or GNUstep, such that each gets its own sub-heirarchy, and files are installed based on policies local to each.
NeXT didn't do it, Sun didn't do it, Apple didn't do it -- Adobe formed to pioneer the display independant display architecture, its use in printing came later. John
Basically, all the programming stuff is pre-executed, and the contents of each page, in terms of Postscript primatives, is canned at each showpage command (well, its a little more, but not much) John
When the target display architecture can't scale up the fonts properly even if asked to by the toolkit. Nor can it scale the line widths effectively. (If you take a look at Xlib, you'll notice that everything is done in terms of pixels, and that's what everything turns to in the end. And even with a theme, how do you synchronise the settings across distant hosts??) John
First, the font system is pixel based. Second, all the other drawing primatives are pixel based. There are no given res independant units to work in, and an extension won't help since not everybody will be using it. Get into the real world -- X is further behind than EVERYTHING else in the market today.
p.s. a target sized theme won't affect the appilcations, you just get a 'normal' sized window frame, and 'anything goes' inside it...
If you ask me, killing the dead horse is a small price to pay for 4000x3000. John
It's EASY to make a CRT with an aribtrarily targetted beam -- think CRO. It's basically impossible to do a colour one. It's also rather difficult to make the image persist (you have to keep redrawing an arbitrary list of vectors. (IIRC, there use to be vector displays, until raster ones took over) John
What you don't get is the ability to say 'My display has a 14.5" visible diagonal, 4:3 apsect ratio, and 1280x1024 pixels' and expect things to be resized accordingly. This really should be here now, given PnP monitors. John
Slashdot Mirror
Problem is, there's no obvious `standard' way of doing so, aside from writing it. What is required is the integration of various tools from document authouring through to software production.
The only standard way of writing descriptive text together with source code is ASCII. Javadoc does too little, as do may other `solutions' for this. A better approach would be to include documentation production into the systems that Source Carpentry are after (so that design/analysis/in-code-documentation are expected parts of a program)
John
Solaris runs ELF binaries, and a typical Sun system will have GNU utilities hanging around it.
That Doesn't Make It Linux
GNU, when its ready, will not be linux, but most likely will use ELF and the GNU utilities
John
Those are POSIX 'capabilities' which are not the same thing as 'capabilities' as in EROS et al.
As reiterated by capability proponents, they are not the same thing
And in case you were wondering, the name clash was POSIX' fault. --- the idea of capabilities as in EROS/KEYKOS/SPEEDOS/etc. predates POSIX (I think), let alone POSIX 'capabilities'
John
What you are describing is a capability system.
Take a look at EROS for a GPL'd example of this.
In particular, note the principal of least privaledge -- just because a program needs one small aspect of root's privaledges, doesn't mean it necessarily needs to be given all of them -- in practice, this gets rid of the root account per se., which is never bad where security is concerned.
John
Some points.
John
The processors alone don't matter that much.
How data is piped from one processor/memory/cluster/etc. to another is what matters -- and then performance will depend heavily on what sort of problems are run on it.
John
A 1300 and 1000 processor T3E(i.e. alpha) has already been done, and the current ASCI systems have >9000(red), >6000(Blue) and ~5800(other blue).
John
In this analogy, the girl has grown up.
You yourself have no right to own her.
John
Hello?? I'm Sorry??
Bandwidth is not intellectual property, and certainly isn't covered by copyright laws.
Slade's bandwidth deal is with his access provider, and any use of it which doesn't contranvene computer misuse acts is legitimate. Importantly, IT IS NOT SUBJECT TO INTELLECTUAL PROPERTY LICENSING -- IT IS THE COPYRIGHTABLE SOFTWARE THAT IS SUBJECT TO LICENSE, AND THAT LICENSE IS THE GPL
Gees, people seem to think that anything may be declared intellectual property, copyright, etc. and licensed.
To anybody who thinks I am saying that all bandwidth is free, I am not. Just that it isn't subject to the same laws as software. In any case, slade is not permitted to place the requirement that the downloader renounce his rights under GPL, since that violates the GPL agreement that HE has agreed to for HIS copy of the software (note that this is independant of any downloaded copies).
John
Why not just dump X and get a decent imaging model as the new standard?
NextStep, OSX, etc. all used the Postscript model, and they get a good part of the flexibility on the display side from this.
Why not just get Ghostscript up and running, and bolt the display stuff onto that??
John
IIRC, the NeWS people did this first --- they were using the precursor to display postscript, which made display-into-icon near trivial.
John
The stampede project should really give two things important weight in the system
- The system should be very 'recompile-centric', i.e. it should be organised such that you can stick the source onto your new machine, set the basic target architecture in some core config file, and then rerun gcc for your system.
Such an approach would make it simple enough to put '-march=k6 -O6 --everything' and then recompile and repackage your entire system (though I think that this places too many demands on the build system --- I'll stop dreaming now)John
make uninstall can, at best, remove the last installed bindle of files, provided that they weren't rearranged -- it can do nothing more.
John
forget files and symlinks -- the configuration system doesn't need the complexity of the entire filesyste, while at the same time it does require extra facilities to be managed efficiently (e.g. how are users' changes stored, what about group configurations (so you have a system default, a group inherits and modifies it, and then users from a particular workgroup may inherit from that, picking up any alterations AS THEY ARE MADE).
The long haul solution is to virtualise the entire user-visible heirachiy, and present THAT in the /usr filesystem (which would then look different dependant upon which user was logged in -- i.e. user filesystem -- with system stuff in /sys for example)
The point that must be reiterated over and over again until understood is that the
In the long run, EVERYTHING must be questioned, from languages to build trees to user-visible filesystem (and what such terms mean).Many people quote the 'Unix approach' as begin 'do it once, do it right'. That is not plausible unless you are prepared to throw away everything that isn't right in persuit of 'doing it right'. Eventually, incremential changes must be binned in favour of a complete redesign, followed by a complete rewrite. (people should take note that a total rewrite alone doesn't work -- you just reinvent what you had before, with a few changes)
John
mandating that the a source tarball expands to something like (relative to e.g. /usr/src)
where all sources go into the source subdirectory, all config/build related stuff into the build subdirectory and the final package files go into e.g. export/i686-pc-linux-gnu/Locations export/i686-pc-linux-gnu/bin/ export/i686-pc-linux-gnu/lib/ export/i686-pc-linux-gnu/include/ export/i686-pc-linux-gnu/share/ which can then be installed from.short, simple, and would make life a lot easier, especially with multiple builds (i.e. debug, normal, fast etc.)
John
Please explain how dependencies could be added to stow without much difficulty? Stow has no procedure for handling multiple instances of the same file in different packages, let alone ensuring that a given package gets the versions of the libraries that it needs (different packages require different versions of libpng, for example).
p.s. stow requires perl, which requires libc, which would get killed by a rm -rf /lib. /usr/local heirarhcy for example, where the files are installed? The former makes things such as GNUstep get rather nasty, since things aren't relative to GNUSTEP_SYSTEM_ROOT, and the latter makes organisiation difficult, since the file->package relations break down.
Also, when make install'ing a program, should the program look directly inside the stow tree for its files, or inside the
In short, more flexible 'framework/build-tree' organisation methods are required for things such as KDE, GNOME or GNUstep, such that each gets its own sub-heirarchy, and files are installed based on policies local to each.
John
Blurry like a TV
John
NeXT didn't do it, Sun didn't do it, Apple didn't do it -- Adobe formed to pioneer the display independant display architecture, its use in printing came later.
John
Anywhere visible yet??
John
PDF 1.3 is a subset of Postscript 3!!!
Basically, all the programming stuff is pre-executed, and the contents of each page, in terms of Postscript primatives, is canned at each showpage command (well, its a little more, but not much)
John
What you need is a float based 'internal positioning metric' with a fast grid fitting algorithm to position the lines.
John
When the target display architecture can't scale up the fonts properly even if asked to by the toolkit. Nor can it scale the line widths effectively. (If you take a look at Xlib, you'll notice that everything is done in terms of pixels, and that's what everything turns to in the end. And even with a theme, how do you synchronise the settings across distant hosts??)
John
X11 is impossible to make resolution independant.
First, the font system is pixel based. Second, all the other drawing primatives are pixel based. There are no given res independant units to work in, and an extension won't help since not everybody will be using it. Get into the real world -- X is further behind than EVERYTHING else in the market today.
p.s. a target sized theme won't affect the appilcations, you just get a 'normal' sized window frame, and 'anything goes' inside it...
If you ask me, killing the dead horse is a small price to pay for 4000x3000.
John
It's EASY to make a CRT with an aribtrarily targetted beam -- think CRO. It's basically impossible to do a colour one. It's also rather difficult to make the image persist (you have to keep redrawing an arbitrary list of vectors. (IIRC, there use to be vector displays, until raster ones took over)
John
What you don't get is the ability to say 'My display has a 14.5" visible diagonal, 4:3 apsect ratio, and 1280x1024 pixels' and expect things to be resized accordingly. This really should be here now, given PnP monitors.
John