Ever considered using Linux (or another Unix, if you like) on an
application server?
Just put XFree86 for Cygwin on your Windows desktops, and then you can
switch between Unix/Windows at will by just pressing Alt+Tab.
X Window System: for font scaling, allows you to choose from 75dpi or 100dpi
That's just for bitmapped fonts, since the X server knows the physical dimensions of the screen (and XFree86 seems to be the nicest implementation since it queries the monitor(s) via DDC and automatically computes the horizontal and vertical resolution). Just run xdpyinfo and look for the "dimensions" and "resolution" lines: you may be surprised.
If your display is in the 100dpi range, it makes more sense to scale bitmapped fonts using bitmaps thought for that resolution, instead that the ones though for a resolution of 72dpi (and vice-versa).
Of course, this is senseless for vectorial fonts, or if one specifies font sizes in pixels instead of tenths of a point.
How long will it take developers to realize that.doc *is* the standard
At least as long as it will take users to realize that.doc is just a dot and three letters, designating a bunch of different file formats.
Incidentally, while reading such file formats is relatively easy, writing them so Word can read them is hard..doc files, in addition to the document itself, contain lots of Word internal garbage: flip the wrong bit in the wrong place and watch Word burn in ashes when opening the document...
It took years of trial and error for the StarOffice guys (and others as well) to get this almost right for the existing versions of Office, so please don't say programmers don't "get it", because this is not true.
Likewise, I miss those big-ass keyboards that click when you type. These flimsy, wussy keyboards that come with modern PCs are terrible! My favorite keyboard was an old IBM AT keyboard from 1984.
Well, to be honest, such keyboards are still sold as new (I doubt they are still manifactured, but there are plenty in stock). You can also order replacement parts there (after all, it's the ex-keyboard division of IBM and Lexmark).
Being a long time Emacs user, Emacs is the obvious choice for me. Btw, EShell
(now part of GNU Emacs 21) makes a good work to bring a nice Un*x
shell on the hosts not having one (i.e. useful if you don't have
Cygwin at hand).
I find also extremely useful the ability of Emacs (thanks to
Ange-FTP) to edit files remotely: is is just as simple as opening
``/username@host:/remote/file/name'', and everything (dired and
completion included) just works as if it was on a local
filesystem, so I don't even have to move from my workstation...
OTOH, for those who like having everyting and the sink but don't
feel comfortable with Emacs, I'd say that JEdit is surely the best
choice for them: it is completely scriptable using BeanShell, a Java-like
scripting language, and has lots and lots of plugins for additional
functionalities.
...have gotten together and somehow agreed on exactly how to do the name mangling
Well, it's not only name mangling, but also how exceptions are handled, how memory is (de)allocated, etc. A C++ ABI is more than just name (de)mangling.
OTOH, there is an ongoing effort to define a common ABI for C++, and GCC 3.x uses that: see here for more info.
Well, go to PCKeyboard and buy
yourself one. PCKeyboard is the ex keyboard division of IBM and
Lexmark, and still has tons of old keyboards (and new ones as well).
"Like changing your Resolution and RefreshRates on the fly might be a nice option."
Well, strictly speaking, changing resolution is already there (Ctrl+Alt+plus/minus on the keypad).
What you really mean is probably to change the desktop size along with the resolution. There is some work in progress on the RandR extension (Rotate AND Resize), which should deal with this (and other interesting things).
Changing refresh rates while the X server is running is already possibile with XFree86, since you can do it using xvidtune (still, you have to copy and paste the modeline it generates if you want your changes to be persistent across sessions). Perhaps, a nicer app to do this wouldn't hurt (volunteers?).
The author incorrectly assets that Linux threads are scheduled by the CPU - he is using the pthreads library, which is userland threading.
Uh?
Last time I checked, "pthread" is just an API, and on Linux you have at least two implementations of that:
linuxthreads (kernel-based, uses the clone() system call, definively scheduled by the kernel), which is the one shipped with GNU libc (the one normally used, and the one used by the author of the article, btw).
.ogg as I understand it is really designed as an audio codec/format
Read better: Ogg is designed to be a generic container for audio/video streams, exactly as Quicktime. The audio codec part is Vorbis, which is shipped inside an Ogg file, hence the full names "Ogg Vorbis".
I don't know why they choose to implement a new container instead of using Quicktime, but probably they have their reasons.
And even the smart ones can get lazy and include a feature just to make life easier or because they forget that "export VAR=value" is just fine in ksh/bash, but not sh.
Fine for ksh and bash, but not sh? It doesn't seem so looking at the Posix 1003.2 draft:
3.14.8 export - Set export attribute for variables
ATI releases specifications of its hardware to developers.
An open DRI driver for Radeon 8500 (which seems to be completely different from Radeon 8800 wrt 3D) based on specs given by ATI has been in the work for some months, but development has been somewhat slow, and it's not ready yet (2D works fine, though).
In the meantime, ATI also released a (proprietary) driver for Radeon 8800 that seems also to provide 3D acceleration for Radeon 8500.
NVIDIA, OTOH, does not release specs, but only proprietary drivers, so there's little if no hope of seeing open drivers for that hardware no matter how much money is thrown at it.
Personally, when I'm asked what video cards are best supported by XFree86, I usually reply "buy an ATI or a Matrox: both have a long tradition of releasing specifications to developers".
if you didn't have to worry about getting them back
If homesickness is prorportional to distance, plus there are doubts on the possibility of a return trip, plus there is no perspective of appropriate medical cares in case of injury... even the strongest-minded of those people would go insane in less than a week.
Could you explain this further? The source code for the Nvidia kernel drivers is available
Just a little portion is available, and not the meaningful one. If you look better at that "source", you'll see it is basically a set of wrappers for that big x86 object file you get in the.tar.gz.
People who laughed at Windows NT being instable due to (possibly) buggy video drivers running in kernel space should consider avoiding proprietary kernel modules as well (and proprietary XFree86 modules - remember that XFree86 runs as root and accesses hardware).
In theory it should be feasible (Wine proves it can be done even for two completely different systems).
In practice I wonder how much overhead you are going to pay (I keep hearing that system calls on Solaris are much more expensive - and consider that each system call in UML in turn would be implemented as several system calls to the hosting system).
GUI shouldn't be a problem: interactive applicatione are usually 99% idle anyways, and using them should be as simple as an "export DISPLAY=..."
OTOH, I/O bound processes probably would be penalized too much, and it would be a good idea to execute then directly on the hosting system.
In the end, if the ability to be root in your very own "partition" is worth the (hypotetic) additional overhead, I'd say "why not?" Of course, some numbers are needed here...
So, let me get this straight... when they go out of their way to prevent piracy, via CSS or protected CDs, that's wrong... but when someone does pirate something, it's their own damned fault for not trying hard enough to prevent it?
If, in order to prevent piracy, they also prevent (or greately encumber in a pure artificial manner) perfectly lawful uses, that's wrong. It's called "throwing away the baby with the dirty water".
As much as I share your desire, I think there is something deeper going on:
IMHO, to attract OSS developers, a piece of software has to be:
Useful to the developer, or at least it should offer the perspective to be useful
in the near future. Otherwise there is very little motivation do mantain/debug software (sorry, I don't buy at all the
idea that a OSS developer puts his time and brain in doing something exclusively for the good of humanity or
users).
Easy to understand, extend and debug: if it isn't easy to grasp the whole picture, or at least grasp the
picture of a whole subsystem, OSS developers will leave the project in frustration after a while,
starting their own. The fact that large (successful) projects like Gnome, KDE, Mozilla and OpenOffice
are divided in several smaller components, and the Linux kernel itself, although monolithic, is divided in
several subsystems, should tell something on the subject.
Well documented (for developers): because it's hard to grasp the big picture only by looking at the sources when
the codebase is large: you end just seeing a lot of trees, but you lose yourself in the forest.
Sources tell a developer how something is implemented and how it is supposed to be
extended, but usually they tell very little on why things have been implemented that way.
Intelligent comments in the code are good, but when a concept spans on several
source files, a README on the subject or a tutorial are definitively needed.
By any way, I don't pretend that these are anything more than a few rules of thumb,
but in the end I'm sure that, for OSS software having the characteristics above, developers
willing to do maintenance will show up by themselves without needing to preach them.
Uhm, what about an aquapad using Midori Linux with an X server on board, eventually with the help of LTSP on the server side (not needed since the Aquapad has its software in a CF card), and perhaps using also rdesktop to access Windows Terminal Server, or VNC to access regular Windows machines (and the ICA client to access Metaframe)?
Technically, the GPL only obliges a distributor to provide source if asked by someone who has received binaries from him.
Technically, if you don't provide access to the sources along with the binaries, you have to provide a written offer (paper) to everyone that received binaries from you. Since this is higly inconvenient for net downloads (tracking everyone), putting up a tarball with the sources is generally simplier.
A little known fact about 1541: it was actually labeled 154l, or 154I, not 1541!
If you have a close look at the label (see here or here: sorry, couldn't find larger pictures), the last character is slightly different from the first (it does not have the oblique little dash like the first, so it is not a ``1'' digit).
OTOH, all the Commodore user documentation reported it as 1541...
Slashdot Mirror
Ever considered using Linux (or another Unix, if you like) on an application server? Just put XFree86 for Cygwin on your Windows desktops, and then you can switch between Unix/Windows at will by just pressing Alt+Tab.
That's just for bitmapped fonts, since the X server knows the physical dimensions of the screen (and XFree86 seems to be the nicest implementation since it queries the monitor(s) via DDC and automatically computes the horizontal and vertical resolution). Just run xdpyinfo and look for the "dimensions" and "resolution" lines: you may be surprised.
If your display is in the 100dpi range, it makes more sense to scale bitmapped fonts using bitmaps thought for that resolution, instead that the ones though for a resolution of 72dpi (and vice-versa).
Of course, this is senseless for vectorial fonts, or if one specifies font sizes in pixels instead of tenths of a point.
How? By using this. Think at Winelib, but proprietary.
At least as long as it will take users to realize that .doc is just a dot and three letters, designating a bunch of different file formats.
Incidentally, while reading such file formats is relatively easy, writing them so Word can read them is hard. .doc files, in addition to the document itself, contain lots of Word internal garbage: flip the wrong bit in the wrong place and watch Word burn in ashes when opening the document...
It took years of trial and error for the StarOffice guys (and others as well) to get this almost right for the existing versions of Office, so please don't say programmers don't "get it", because this is not true.
Linus said that is a relly bad idea if you compile things by yourself, but I admit I don't know if that is still a valid argument.
Well, it would just be only a special case of the Troutman's Laws of Computer Programming (see law #5).
After all, 640 megabytes should be enough for everyone... oh, wait... :-)
Well, to be honest, such keyboards are still sold as new (I doubt they are still manifactured, but there are plenty in stock). You can also order replacement parts there (after all, it's the ex-keyboard division of IBM and Lexmark).
I find also extremely useful the ability of Emacs (thanks to Ange-FTP) to edit files remotely: is is just as simple as opening ``/username@host:/remote/file/name'', and everything (dired and completion included) just works as if it was on a local filesystem, so I don't even have to move from my workstation...
OTOH, for those who like having everyting and the sink but don't feel comfortable with Emacs, I'd say that JEdit is surely the best choice for them: it is completely scriptable using BeanShell, a Java-like scripting language, and has lots and lots of plugins for additional functionalities.
Well, it's not only name mangling, but also how exceptions are handled, how memory is (de)allocated, etc. A C++ ABI is more than just name (de)mangling.
OTOH, there is an ongoing effort to define a common ABI for C++, and GCC 3.x uses that: see here for more info.
Well, go to PCKeyboard and buy yourself one. PCKeyboard is the ex keyboard division of IBM and Lexmark, and still has tons of old keyboards (and new ones as well).
Well, strictly speaking, changing resolution is already there (Ctrl+Alt+plus/minus on the keypad).
What you really mean is probably to change the desktop size along with the resolution. There is some work in progress on the RandR extension (Rotate AND Resize), which should deal with this (and other interesting things).
Changing refresh rates while the X server is running is already possibile with XFree86, since you can do it using xvidtune (still, you have to copy and paste the modeline it generates if you want your changes to be persistent across sessions). Perhaps, a nicer app to do this wouldn't hurt (volunteers?).
Uh?
Last time I checked, "pthread" is just an API, and on Linux you have at least two implementations of that:
IBM is also working to implement a M:N threading implementation with a pthread API, partially kernel-based and partially in userland.
Read better: Ogg is designed to be a generic container for audio/video streams, exactly as Quicktime. The audio codec part is Vorbis, which is shipped inside an Ogg file, hence the full names "Ogg Vorbis".
I don't know why they choose to implement a new container instead of using Quicktime, but probably they have their reasons.
Fine for ksh and bash, but not sh? It doesn't seem so looking at the Posix 1003.2 draft:
ATI releases specifications of its hardware to developers.
An open DRI driver for Radeon 8500 (which seems to be completely different from Radeon 8800 wrt 3D) based on specs given by ATI has been in the work for some months, but development has been somewhat slow, and it's not ready yet (2D works fine, though).
In the meantime, ATI also released a (proprietary) driver for Radeon 8800 that seems also to provide 3D acceleration for Radeon 8500.
NVIDIA, OTOH, does not release specs, but only proprietary drivers, so there's little if no hope of seeing open drivers for that hardware no matter how much money is thrown at it.
Personally, when I'm asked what video cards are best supported by XFree86, I usually reply "buy an ATI or a Matrox: both have a long tradition of releasing specifications to developers".
If homesickness is prorportional to distance, plus there are doubts on the possibility of a return trip, plus there is no perspective of appropriate medical cares in case of injury... even the strongest-minded of those people would go insane in less than a week.
We are just humans, slaves of our fears.
Just a little portion is available, and not the meaningful one. If you look better at that "source", you'll see it is basically a set of wrappers for that big x86 object file you get in the .tar.gz.
People who laughed at Windows NT being instable due to (possibly) buggy video drivers running in kernel space should consider avoiding proprietary kernel modules as well (and proprietary XFree86 modules - remember that XFree86 runs as root and accesses hardware).
In theory it should be feasible (Wine proves it can be done even for two completely different systems).
In practice I wonder how much overhead you are going to pay (I keep hearing that system calls on Solaris are much more expensive - and consider that each system call in UML in turn would be implemented as several system calls to the hosting system).
GUI shouldn't be a problem: interactive applicatione are usually 99% idle anyways, and using them should be as simple as an "export DISPLAY=..."
OTOH, I/O bound processes probably would be penalized too much, and it would be a good idea to execute then directly on the hosting system.
In the end, if the ability to be root in your very own "partition" is worth the (hypotetic) additional overhead, I'd say "why not?" Of course, some numbers are needed here...
If, in order to prevent piracy, they also prevent (or greately encumber in a pure artificial manner) perfectly lawful uses, that's wrong. It's called "throwing away the baby with the dirty water".
It's just simple as that.
IMHO, to attract OSS developers, a piece of software has to be:
By any way, I don't pretend that these are anything more than a few rules of thumb, but in the end I'm sure that, for OSS software having the characteristics above, developers willing to do maintenance will show up by themselves without needing to preach them.
It doesn't seem to be a new concept at all.
Technically, if you don't provide access to the sources along with the binaries, you have to provide a written offer (paper) to everyone that received binaries from you. Since this is higly inconvenient for net downloads (tracking everyone), putting up a tarball with the sources is generally simplier.
And even if your wallet is not enough evidence: Perl is Instrumental in Data Warehouse for Italy's Top Bank.
If you have a close look at the label (see here or here: sorry, couldn't find larger pictures), the last character is slightly different from the first (it does not have the oblique little dash like the first, so it is not a ``1'' digit).
OTOH, all the Commodore user documentation reported it as 1541...