a Unix kernel and a Mac GUI, the perfect computer!
There's a big assumption there: that the Mac GUI
is actually something the user would prefer.
Personally, the Mac GUI drives me batshit, for much the same reason as the Windows GUI: it
won't let me interact with partially-obscured windows. And yes I do find myself wanting to do this quite often (and unfortunately am reminded of it the hard way whenever I use one of the Windows machines in the office).
The single-menu-bar design that the Mac GUI has pretty much mandates the "current application" concept, so it's not like they can trivially add a focus-follows-mouse option like most X11 windows managers have.
<rant>
But wait, it gets worse! Mac users will sometimes tout how great Apple's support is for multi-head systems. And it's certainly true that from an OS viewpoint it works quite nicely: the monitors don't need to run the same resolution, or even at the same color depth, and you can easily adjust their relative positions with a configuration panel.
But have you ever tried to use a multi-head Mac? A friend had a dual 1600x1200 Mac, which I did spend quite a bit of time with. The second display was almost useless, because the "single menu" implementation only put the menu on the top of one screen. So if you were working with an application on the "other" screen, getting the pointer to/from that damn menu was a major trek. I asked several folks who were much more familiar with the Mac GUI if there was any way to get the menu to appear on all screens, or perhaps follow you between screens automatically, but none ever had a solution.
Mac GUI enthusiasts will talk about how Fitts's law makes the menu easily accessible, but frankly Apple's multi-head implementation completely b0rk'd any benefits from Fitts.
And don't even get me started on the hardware. Take for example the Studio Display (tube) monitors, which are PC VGA compatible (well, mostly; apparently they don't like certain Shuttle motherboards), but can only be adjusted for things like screen size and position via USB -- and Linux doesn't seem to even see them as a device on the USB bus, much less have a driver to talk to them.
</rant>
The FSF used to boycott Apple in exactly the same way they have now decided not to boycott SCO,
You can still find the anti-Apple stuff in older source trees on ftp.gnu.org. For example from the GNU emacs 18.59 documentation:
We are boycotting Apple because of Apple's efforts to take away
our freedom to write compatible imitations of existing software.
If you value your freedom to write such programs, we urge you
not to buy from Apple, not to develop software for Apple, and
certainly not to accept a job with Apple.
It then points to a separate document (also included) which explained their position in much more detail.
Component is so last year. DVI is the way to go for HD.
Isn't there some issue about DVI not always
being able to handle HD resolutions and/or refresh rates?
For real bragging rights, convert your video equipment to HD-SDI. This is the SMPTE standard for uncompressed HD, used in HDTV production and broadcast environments. The downside is that HD-SDI hardware is crazy expensive; figure $5K for an output card, $8K or more for a capture card, and so on.
why do I need to have multiple versions of libraries installed simultaneously on a server?
On a server? Perhaps not. Most of my interest in this comes from dealing with my workstation configuration. Such as wanting to try out some new application or library version on a whim without potentially breaking anything else on the machine. Since I build from source 99.44% of the time I currently make a new install prefix and put everything (all dependencies except maybe libc and libz) there; but that means that if I have four different things using some unstable or new version of libfoo I might end up with four copies of the same version of libfoo lying around for different reasons.
Couldn't I upgrade to newer versions of the programs that use each library, instead?
If they exist. And I don't want the old version of the program clobbered until I'm sure that the new one is stable and doesn't have some new misfeature.
couldn't library others NOT break backwards-compatibility?
There's no infrastructure policy such as Apple's
that forces it. Library and application writers could maintain compatibility, but that doesn't mean that they always do. I prefer the system to defend itself so that I don't have to worry about whether they do or not.
And remember that this isn't just a matter of single libraries. One of the main reasons DragonFly appears to be looking at this is to handle large updates where many pieces and packages have to be replaced. For example just to update gtk2 you're looking at a large number of libraries from different development trees (pango, freetype, pkgconf, etc). As you do the upgrade and the new minor versions clobber the old ones one by one, you have lots of intermediate stages where the dependencies on your system are broken and libraries might actively mismatch.
I guess you will "somehow" have to tell gcc (or the make that runs it, or the shell that runs the make that runs gcc) what file name space you want.
I'm very interested in seeing how DragonFly handles the administrative part of this. If this packaging system can be implemented in Linux it'd be nice to have the same commands/tools on both operating systems.
Maybe the package system will insist they are installed in different places in the "real file name space" and just map them into the "same place" in the file name space for packages.
That was my thinking about how it could be handled if implemented for Linux. The writeup for DragonFly suggests the idea of embedding a version suffix into file and/or directory names, which would be hidden when viewing them through the packaging layer.
What if I don't want the newest version to be used?
Which version of the library do the system header files match?
And how do you handle the case where two minor versions of a library produce the same libfoo.so.* file?
A basic problem here is the whole concept of a globally current version, especially since the system will normally assume the most recent version is the one you want. What if I've installed some prerelease or development version for testing? I don't want all of my applications automatically picking that up just because the system assumes it's ABI-compatible.
Correct me if I'm wrong, but I believe the Mac OS X frameworks mechanism does the same thing (multiple versions of the same dylib). Applications link at runtime to the same version they were built against, even though a newer or older version of the library may be installed.
Yes, frameworks do something similar. But the design requires toolchains, runtime linking, and the libraries themselves to understand frameworks.
So do you modify the applications and libraries to understand a new way of working, or modify the system so that the new way looks (to userspace code) just like the old way? Apple can take the former, arguably better route, because they control the system and can force everybody to play along. Linux on the other hand has this huge installed base that isn't going to budge until the new way becomes the common way. I have in the past done things like modify an application (and all of the libraries it depends on) to be relocatable and take a runtime prefix from an environment variable -- but that gets painful very quickly, and maintaining it is almost out of the question.
Frameworks have the concept of a globally "current" library version, which takes precedence all the time. In the DragonFly approach (or at least in my similar dream design:-) all installed versions of a library have equal standing. The "current" version in my case is whatever version you want to be current at the moment, in the context of that specific running process.
Frameworks also seem to have a requirement for forward compatibility in minor versions of libraries. If you link your application against version 1.3.x of a library, and you install 1.4.x on the system, the next time you run the application it will get linked against 1.4.x, unconditionally. At least that's what Apple's docs seem to say. This puts the burden on software authors to maintain this sort of compatibility guarantee. Frankly I don't trust Linux library authors that much, especially since they don't have anyone forcing it on them. I want a chance to test some older applications against 1.4.x, and I want the option of having those applications stay with 1.3.x if there turns out to be problems, even while 1.4.x is installed for other, newer applications and libraries to use.
I think the VMS filesystem did file versioning similar to this.
I don't really know enough about the workings of VMS to say for sure. I think the VMS approach works on an individual file basis. I suspect that the versioning in the case of DragonFlyBSD will need to group files together into packages. Packages will have their dependencies explicitly stated somehow; for
example the DragonFly writeup refers to the idea of a cron job that automatically cleans up unneeded packages after an upgrade.
So for example, you have libfoo 1.3.2 installed already, and you see that 1.3.3 is available. You should be able to install the newer version and all related files (such as gettext strings) as a single entity. Programs using 1.3.2 will see no change at all; they still get the old code when they link with "/usr/local/lib/libfoo.*". They can't even see that 1.3.3 is there. You would then be able to switch those applications over to 1.3.3 for testing, one at a time, by telling the operating system to make 1.3.3 visible to them.
Again, all related files that came with libfoo 1.3.2 or 1.3.3 have their visibility affected by this one change. The application still links with the same libfoo.* file, using the same full path, but gets the newer code
transparently. When all applications that used 1.3.2 have been migrated to the new version and tested successfully, the old package can be removed safely (and the system will know this because it knows all of the active dependencies explicitly).
The really nice thing here is that you can use this to upgrade some massive multi-package thing like Gnome, where there are a zillion sublibraries and packages with dependencies on each other. They can be installed right on top of the older versions, with all of their new dependencies intact, with no effect on installed applications that are using the old libs. And you can take your time doing it, since the old libs are never clobbered and the system remains stable.
When compiling, you should be able to specify which set of libraries you want visible. So for example I wouldn't have to worry about some configure script scrounging through my machine and finding libraries that I don't want it to know about. On my current system, I might have all sorts of things installed for testing purposes, or that I'm planning to get rid of, and they might be in my default library path because right now that's the only convenient way for other applications to find them. Then I forget to strip those paths down to the bare mininum and find that something I just compiled has an unwanted dependency or linkage to one of those libs.
Of course there are all sorts of subtle issues with implementing something like this on Linux. For example ld.so.cache isn't necessarily even a valid concept any more.
Are they talking about replacing the ports system?
It's more than just replacing ports with portage, or apt-get, or some other userspace packaging
system.
What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An
application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.
To which I say:
HALLELUJAH BROTHER!
This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.
In any case, this is not just a userspace change. This involves the kernel itself.
I find these comments quite funny, but that may be because they hit so close to home.
For my main ISP account I currently use
"mailx" to read mail, and "sendmail -t" to
send replies. Seriously.
At work I was dragged off of mailx some years
ago, but only by a specific internally-developed and customized mail client. When it comes to things like Outlook,
Netscape/Mozilla, or any workalike that has
that combined mailboxes+messagelist+text design, I pretty
much hate them all. I've tried using Sylpheed
for one account and while it's tolerable I can't really say I enjoy it (e.g. there are some issues with keyboard navigation).
For newsreading, I use an old version
of a trn 3 derivative. I tried upgrading to
trn 4 but could not find a way (short of
modifying the code) to keep it
from ever clearing the screen, so that was the
end of that.
Indeed, the first thing I looked for in the Toshiba specs was the screen resolution. It seems this giant 17" screen is a mere 1400x900 pixels. That's all I have to see to kill any thoughts about getting one.
Thats what I find dumb about 17" LCD screens, few are 1600x, most are 1280, yet dell makes laptops with 1600x res
It's even worse than that. Dell apparently has a laptop with a 15.4" 1920x1200 widescreen, yet even they don't seem to have any standalone panels with decent pixel density. You have to go to 20" to get anything better than 1280x1024; it's ridiculous.
What we need are the _[]x window buttons on the keyboard so that we can minimize, maxamize and close windows with 1 push of a keyboard button.
Imagine a keyboard even wider than a typical
PC keyboard, with an extra keypad on the left side plus a few extra keys scattered here and there. Keys such as:
insert/mark
delete line
delete character
cut/copy
undo/paste
move/grow (for adjusting window placement)
start of line
end of line
page left
page right
go to next window (sort of like alt-tab)
repeat
pop (for raising/lowering windows)
again
read file
save/edit
abort/exit
help/hold (sort of like scroll lock)
enter command or start shell
This keyboard is what you might find attached
to an Apollo system. Apollo made graphical Unix workstations in the 1980's, competing mainly with Sun. They had a custom GUI environment dating back to maybe 1983, if not earlier. Pretty much the entire interface, including window management, could be done from the keyboard if you so desired. The GUI had a macro layer between the keyboard and applications, so you could reprogram/remap the keys on a per-user
basis.
Apollo keyboards also typically had the control key next to the caps lock key, which works for both emacs users and non-typists who can't deal with a shift key.
HP bought the company and phased out the hardware
(and Apollo's operating system) during the 90's.
Unfortunately I believe these keyboards, as with
everything else Apollo did, were extremely proprietary. For example last I checked you could run the BSDs on some HP/Apollo hardware but only if you were using the "HP-UX" model keyboard
instead.
Caveat: emacs is usually the first thing I start when I log in and the last thing I quit before logging out, but I do occasionally use vi. Friends who are vi-diehards have mentioned this same issue...
A vi user can look at vi, with its fairly minimal set of features, and not wish for much more at all. This is because the vi user expects his editor to just be an editor and nothing else.
If only that were true. Unfortunately there have
been occasions, usually with major Linux distributions, where I've run "vi" and found that it was really some uber-enhanced monstrosity pretending to be vi. For example "vi foo.html" has sometimes resulted in interpreted HTML with bolding, coloring, and no visible tags.
Perhaps there's some type of projector out there that can switch frames quick enough for the eye to not detect flicker,
Just a data point: the flicker you see in a movie theater is usually 48 flashes per second. Each
film frame is displayed twice.
I've heard of 48fps theatres in France, but obviously not a lot is being made for them.
Roger Ebert has been talking about some
true 48fps system
for a while now, so that might be what they're
using in those theaters.
For about 20 years there has been a 70mm 60fps format called Showscan, but I don't recall if they ever managed to create a feature film with it. It ended up being used for theme rides.
I certainly am not familiar with every set, but I've never seen one that downconverts
1080i to 540p. Maybe the very low-end ones do.
At least some sets take the 1080i, treat it
as 540p, drop the top and bottom 30 lines
to get 480p, and then display that.
I know the Sony W400Q (circa 1998) does this,
and I've heard that some plasma screens
work the same way.
I think some rear projectors a few years ago
were based around displaying 540p. I don't
know what the current sets are doing, but I
wouldn't be surprised if the LCOS/LCD/DLP-based
ones were playing games with the image.
This has got to be the worst review I've ever seen in my life.
A quick search over at avsforum produces some detailed reviews. The general verdict from
several owners is that it's not a very good
scaler or deinterlacer. Not really surprising
considering the low price ("low" relative to good scalers and deinterlacers:-)
which allowed him to hook a DVD player up directly to a digital flat panel via DVI or some other such format.
They banned the device because it was decoding the data and passing it out in a DATA format (or digital)
These folks sell
SDI (serial digital interface) output modifications for DVD players. What
this basically does is tap the output of the
MPEG decoder and send it out as a purely
digital data stream. You can then feed that into
a scaler (with SDI input, of course) and
produce whatever resolution you want.
If a TV has HDTV compliant sticker on it (and 3x the sticker price to boot of course) it
damn well should display 1920x1080i
If the TV makers had their way they'd be
marketing "high definition" sets that couldn't
sync any of the high resolution
formats. In fact I think one or two sets
made it out the door that way before the folks
responsible for HDTV standards put a stop to it.
Even so, you cannot buy any LCD or DLP
projector today that has 1920x1080 resolution,
unless perhaps you have $100K to spend and can
supply a couple kilowatts of power.
Various conspiracy theories suggest that this is fully
intentional on the part of the projector makers
(mainly TI and JVC in this case), and that they
are only going to supply full resolution
projectors for large-venue theaters.
Sony recently announced that they will
have a
consumer 1920x1080 projector (based on
their implementation of LCOS) out within the
year. Some folks at avsforum claim to have
already seen working prototypes. Given a
$3K price point, they could pretty
much own the home theater projector market by
this time next year. Unfortunately the expected
price is more like $8K-$12K.
but now I'm thinking "they" (marketers / hollywood?) - will be making "HD-DVD"
with 1920x1080 data but my TV won't ACTUALLY display it all
More likely the Hollywood folks will drag their
heels for as long as possible on providing
HD DVDs of any sort, and when they do come out
they'll be extremely compressed with the
lowest quality they can get away with. See
the One Format
Only campaign.
There's terrestrial, but obviously that
depends on how close you are to the local
broadcasters. I'm between two major markets and
can generally get at least one digital signal
from each of the networks. But of course most of
them don't transmit HD all the time, and there
are cases like FOX that won't do HD at all.
Any digital cable I've seen doesn't do HDTV, maybe some do but I've not seen any.
Comcast has rolled out HD on digital cable in
the Baltimore/Washington area. As I understand
it they offer HBO, Showtime, and a couple of the
local affiliates in HD. A friend is due to get the
box tomorrow and it'll be interesting to see how
it looks.
There's a guy here who's incredibly proud of the fact that he's "had to" spend $150 on cables to connect his bp2002 fronts. He claims that with cheap $75 cables he wouldn't be getting the same sound quality and he'd be wasting his speakers.
Bah, $150 is chump change. If he just wants some expensive cables, he can get a pair of Opus MM speaker cables for around $23K. And don't forget the $1000 power cables for each component. Not to mention high-end power outlets and/or regenerators. You mean your outlets use steel screws to connect to house wiring instead of brass? Ha! They're useless!:-)
And this isn't even close to being the absurd stuff. This guy sells a pen that he claims will improve the sound quality of CDs by writing affirmative messages on their jacket covers. I have seen audiophile discussion boards where making fun of such products will get you flamed; "how can you say it doesn't work if you haven't tried it"?
Nothing irks me more than people who believe that the money:quality ratio is constant.
I generally just build my own cables these days. For example I've found Belden 8281 (a 75ohm coax normally used to wire broadcast studios) for as little as $0.10/foot from folks who just want to get excess spools out of their warehouse. The tools and terminators easily end up being more expensive than the cable itself. I've also tried a few more exotic things like DIY braided power cords, which did reduce a ground loop I was having at the time but are mostly just a fun project even if they don't make a noticable improvement.
Slashdot Mirror
There's a big assumption there: that the Mac GUI is actually something the user would prefer.
Personally, the Mac GUI drives me batshit, for much the same reason as the Windows GUI: it won't let me interact with partially-obscured windows. And yes I do find myself wanting to do this quite often (and unfortunately am reminded of it the hard way whenever I use one of the Windows machines in the office).
The single-menu-bar design that the Mac GUI has pretty much mandates the "current application" concept, so it's not like they can trivially add a focus-follows-mouse option like most X11 windows managers have.
<rant>
But wait, it gets worse! Mac users will sometimes tout how great Apple's support is for multi-head systems. And it's certainly true that from an OS viewpoint it works quite nicely: the monitors don't need to run the same resolution, or even at the same color depth, and you can easily adjust their relative positions with a configuration panel.
But have you ever tried to use a multi-head Mac? A friend had a dual 1600x1200 Mac, which I did spend quite a bit of time with. The second display was almost useless, because the "single menu" implementation only put the menu on the top of one screen. So if you were working with an application on the "other" screen, getting the pointer to/from that damn menu was a major trek. I asked several folks who were much more familiar with the Mac GUI if there was any way to get the menu to appear on all screens, or perhaps follow you between screens automatically, but none ever had a solution. Mac GUI enthusiasts will talk about how Fitts's law makes the menu easily accessible, but frankly Apple's multi-head implementation completely b0rk'd any benefits from Fitts.
And don't even get me started on the hardware. Take for example the Studio Display (tube) monitors, which are PC VGA compatible (well, mostly; apparently they don't like certain Shuttle motherboards), but can only be adjusted for things like screen size and position via USB -- and Linux doesn't seem to even see them as a device on the USB bus, much less have a driver to talk to them.
</rant>
You can still find the anti-Apple stuff in older source trees on ftp.gnu.org. For example from the GNU emacs 18.59 documentation:
It then points to a separate document (also included) which explained their position in much more detail.
It's not complicated, it's just hard to type :-)
A language like C has a much more complex syntax, with many operators, special characters, and keywords that are all context-sensitive.
Isn't there some issue about DVI not always being able to handle HD resolutions and/or refresh rates?
For real bragging rights, convert your video equipment to HD-SDI. This is the SMPTE standard for uncompressed HD, used in HDTV production and broadcast environments. The downside is that HD-SDI hardware is crazy expensive; figure $5K for an output card, $8K or more for a capture card, and so on.
On a server? Perhaps not. Most of my interest in this comes from dealing with my workstation configuration. Such as wanting to try out some new application or library version on a whim without potentially breaking anything else on the machine. Since I build from source 99.44% of the time I currently make a new install prefix and put everything (all dependencies except maybe libc and libz) there; but that means that if I have four different things using some unstable or new version of libfoo I might end up with four copies of the same version of libfoo lying around for different reasons.
If they exist. And I don't want the old version of the program clobbered until I'm sure that the new one is stable and doesn't have some new misfeature.
There's no infrastructure policy such as Apple's that forces it. Library and application writers could maintain compatibility, but that doesn't mean that they always do. I prefer the system to defend itself so that I don't have to worry about whether they do or not.
And remember that this isn't just a matter of single libraries. One of the main reasons DragonFly appears to be looking at this is to handle large updates where many pieces and packages have to be replaced. For example just to update gtk2 you're looking at a large number of libraries from different development trees (pango, freetype, pkgconf, etc). As you do the upgrade and the new minor versions clobber the old ones one by one, you have lots of intermediate stages where the dependencies on your system are broken and libraries might actively mismatch.
I'm very interested in seeing how DragonFly handles the administrative part of this. If this packaging system can be implemented in Linux it'd be nice to have the same commands/tools on both operating systems.
That was my thinking about how it could be handled if implemented for Linux. The writeup for DragonFly suggests the idea of embedding a version suffix into file and/or directory names, which would be hidden when viewing them through the packaging layer.
What if I don't want the newest version to be used?
Which version of the library do the system header files match?
And how do you handle the case where two minor versions of a library produce the same libfoo.so.* file?
A basic problem here is the whole concept of a globally current version, especially since the system will normally assume the most recent version is the one you want. What if I've installed some prerelease or development version for testing? I don't want all of my applications automatically picking that up just because the system assumes it's ABI-compatible.
Yes, frameworks do something similar. But the design requires toolchains, runtime linking, and the libraries themselves to understand frameworks. So do you modify the applications and libraries to understand a new way of working, or modify the system so that the new way looks (to userspace code) just like the old way? Apple can take the former, arguably better route, because they control the system and can force everybody to play along. Linux on the other hand has this huge installed base that isn't going to budge until the new way becomes the common way. I have in the past done things like modify an application (and all of the libraries it depends on) to be relocatable and take a runtime prefix from an environment variable -- but that gets painful very quickly, and maintaining it is almost out of the question.
Frameworks have the concept of a globally "current" library version, which takes precedence all the time. In the DragonFly approach (or at least in my similar dream design :-) all installed versions of a library have equal standing. The "current" version in my case is whatever version you want to be current at the moment, in the context of that specific running process.
Frameworks also seem to have a requirement for forward compatibility in minor versions of libraries. If you link your application against version 1.3.x of a library, and you install 1.4.x on the system, the next time you run the application it will get linked against 1.4.x, unconditionally. At least that's what Apple's docs seem to say. This puts the burden on software authors to maintain this sort of compatibility guarantee. Frankly I don't trust Linux library authors that much, especially since they don't have anyone forcing it on them. I want a chance to test some older applications against 1.4.x, and I want the option of having those applications stay with 1.3.x if there turns out to be problems, even while 1.4.x is installed for other, newer applications and libraries to use.
The CrossOver Office folks say that they support Photoshop 7 on Linux.
I don't really know enough about the workings of VMS to say for sure. I think the VMS approach works on an individual file basis. I suspect that the versioning in the case of DragonFlyBSD will need to group files together into packages. Packages will have their dependencies explicitly stated somehow; for example the DragonFly writeup refers to the idea of a cron job that automatically cleans up unneeded packages after an upgrade.
So for example, you have libfoo 1.3.2 installed already, and you see that 1.3.3 is available. You should be able to install the newer version and all related files (such as gettext strings) as a single entity. Programs using 1.3.2 will see no change at all; they still get the old code when they link with "/usr/local/lib/libfoo.*". They can't even see that 1.3.3 is there. You would then be able to switch those applications over to 1.3.3 for testing, one at a time, by telling the operating system to make 1.3.3 visible to them. Again, all related files that came with libfoo 1.3.2 or 1.3.3 have their visibility affected by this one change. The application still links with the same libfoo.* file, using the same full path, but gets the newer code transparently. When all applications that used 1.3.2 have been migrated to the new version and tested successfully, the old package can be removed safely (and the system will know this because it knows all of the active dependencies explicitly).
The really nice thing here is that you can use this to upgrade some massive multi-package thing like Gnome, where there are a zillion sublibraries and packages with dependencies on each other. They can be installed right on top of the older versions, with all of their new dependencies intact, with no effect on installed applications that are using the old libs. And you can take your time doing it, since the old libs are never clobbered and the system remains stable.
When compiling, you should be able to specify which set of libraries you want visible. So for example I wouldn't have to worry about some configure script scrounging through my machine and finding libraries that I don't want it to know about. On my current system, I might have all sorts of things installed for testing purposes, or that I'm planning to get rid of, and they might be in my default library path because right now that's the only convenient way for other applications to find them. Then I forget to strip those paths down to the bare mininum and find that something I just compiled has an unwanted dependency or linkage to one of those libs.
Of course there are all sorts of subtle issues with implementing something like this on Linux. For example ld.so.cache isn't necessarily even a valid concept any more.
It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.
What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.
To which I say: HALLELUJAH BROTHER!
This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.
In any case, this is not just a userspace change. This involves the kernel itself.
I find these comments quite funny, but that may be because they hit so close to home. For my main ISP account I currently use "mailx" to read mail, and "sendmail -t" to send replies. Seriously.
At work I was dragged off of mailx some years ago, but only by a specific internally-developed and customized mail client. When it comes to things like Outlook, Netscape/Mozilla, or any workalike that has that combined mailboxes+messagelist+text design, I pretty much hate them all. I've tried using Sylpheed for one account and while it's tolerable I can't really say I enjoy it (e.g. there are some issues with keyboard navigation).
For newsreading, I use an old version of a trn 3 derivative. I tried upgrading to trn 4 but could not find a way (short of modifying the code) to keep it from ever clearing the screen, so that was the end of that.
I'm admittedly a little set in my ways... :-)
Indeed, the first thing I looked for in the Toshiba specs was the screen resolution. It seems this giant 17" screen is a mere 1400x900 pixels. That's all I have to see to kill any thoughts about getting one.
It's even worse than that. Dell apparently has a laptop with a 15.4" 1920x1200 widescreen, yet even they don't seem to have any standalone panels with decent pixel density. You have to go to 20" to get anything better than 1280x1024; it's ridiculous.
Imagine a keyboard even wider than a typical PC keyboard, with an extra keypad on the left side plus a few extra keys scattered here and there. Keys such as:
This keyboard is what you might find attached to an Apollo system. Apollo made graphical Unix workstations in the 1980's, competing mainly with Sun. They had a custom GUI environment dating back to maybe 1983, if not earlier. Pretty much the entire interface, including window management, could be done from the keyboard if you so desired. The GUI had a macro layer between the keyboard and applications, so you could reprogram/remap the keys on a per-user basis.
Apollo keyboards also typically had the control key next to the caps lock key, which works for both emacs users and non-typists who can't deal with a shift key.
HP bought the company and phased out the hardware (and Apollo's operating system) during the 90's. Unfortunately I believe these keyboards, as with everything else Apollo did, were extremely proprietary. For example last I checked you could run the BSDs on some HP/Apollo hardware but only if you were using the "HP-UX" model keyboard instead.
Caveat: emacs is usually the first thing I start when I log in and the last thing I quit before logging out, but I do occasionally use vi. Friends who are vi-diehards have mentioned this same issue...
If only that were true. Unfortunately there have been occasions, usually with major Linux distributions, where I've run "vi" and found that it was really some uber-enhanced monstrosity pretending to be vi. For example "vi foo.html" has sometimes resulted in interpreted HTML with bolding, coloring, and no visible tags.
When I ask for "vi", I want "vi", dammit.
Just a data point: the flicker you see in a movie theater is usually 48 flashes per second. Each film frame is displayed twice.
Roger Ebert has been talking about some true 48fps system for a while now, so that might be what they're using in those theaters.
For about 20 years there has been a 70mm 60fps format called Showscan, but I don't recall if they ever managed to create a feature film with it. It ended up being used for theme rides.
Probably, since AU and NZ currency are printed by the same company in Australia -- at least they were a few years ago: press release.
- pick a DDR mix (there's many to choose from if you have both US and JP consoles)
- set skill level to heavy/maniac
- play every song at least once
This takes maybe 3 hours, including some stretching and an extremely necessary showerAt least some sets take the 1080i, treat it as 540p, drop the top and bottom 30 lines to get 480p, and then display that. I know the Sony W400Q (circa 1998) does this, and I've heard that some plasma screens work the same way.
I think some rear projectors a few years ago were based around displaying 540p. I don't know what the current sets are doing, but I wouldn't be surprised if the LCOS/LCD/DLP-based ones were playing games with the image.
A quick search over at avsforum produces some detailed reviews. The general verdict from several owners is that it's not a very good scaler or deinterlacer. Not really surprising considering the low price ("low" relative to good scalers and deinterlacers :-)
which allowed him to hook a DVD player up directly to a digital flat panel via DVI or some other such format.
They banned the device because it was decoding the data and passing it out in a DATA format (or digital)
These folks sell SDI (serial digital interface) output modifications for DVD players. What this basically does is tap the output of the MPEG decoder and send it out as a purely digital data stream. You can then feed that into a scaler (with SDI input, of course) and produce whatever resolution you want.
The downside: it ain't cheap :-)
If the TV makers had their way they'd be marketing "high definition" sets that couldn't sync any of the high resolution formats. In fact I think one or two sets made it out the door that way before the folks responsible for HDTV standards put a stop to it.
Even so, you cannot buy any LCD or DLP projector today that has 1920x1080 resolution, unless perhaps you have $100K to spend and can supply a couple kilowatts of power. Various conspiracy theories suggest that this is fully intentional on the part of the projector makers (mainly TI and JVC in this case), and that they are only going to supply full resolution projectors for large-venue theaters.
Sony recently announced that they will have a consumer 1920x1080 projector (based on their implementation of LCOS) out within the year. Some folks at avsforum claim to have already seen working prototypes. Given a $3K price point, they could pretty much own the home theater projector market by this time next year. Unfortunately the expected price is more like $8K-$12K.
but now I'm thinking "they" (marketers / hollywood?) - will be making "HD-DVD" with 1920x1080 data but my TV won't ACTUALLY display it allMore likely the Hollywood folks will drag their heels for as long as possible on providing HD DVDs of any sort, and when they do come out they'll be extremely compressed with the lowest quality they can get away with. See the One Format Only campaign.
Horizontal sync rate, which seems to be a pretty critical measurement as far as monitor circuitry is concerned.
There's terrestrial, but obviously that depends on how close you are to the local broadcasters. I'm between two major markets and can generally get at least one digital signal from each of the networks. But of course most of them don't transmit HD all the time, and there are cases like FOX that won't do HD at all.
Any digital cable I've seen doesn't do HDTV, maybe some do but I've not seen any.Comcast has rolled out HD on digital cable in the Baltimore/Washington area. As I understand it they offer HBO, Showtime, and a couple of the local affiliates in HD. A friend is due to get the box tomorrow and it'll be interesting to see how it looks.
Bah, $150 is chump change. If he just wants some expensive cables, he can get a pair of Opus MM speaker cables for around $23K. And don't forget the $1000 power cables for each component. Not to mention high-end power outlets and/or regenerators. You mean your outlets use steel screws to connect to house wiring instead of brass? Ha! They're useless!
And this isn't even close to being the absurd stuff. This guy sells a pen that he claims will improve the sound quality of CDs by writing affirmative messages on their jacket covers. I have seen audiophile discussion boards where making fun of such products will get you flamed; "how can you say it doesn't work if you haven't tried it"?
I generally just build my own cables these days. For example I've found Belden 8281 (a 75ohm coax normally used to wire broadcast studios) for as little as $0.10/foot from folks who just want to get excess spools out of their warehouse. The tools and terminators easily end up being more expensive than the cable itself. I've also tried a few more exotic things like DIY braided power cords, which did reduce a ground loop I was having at the time but are mostly just a fun project even if they don't make a noticable improvement.