You know, uh, when someone like Fedora wants to test a package before accepting it into say, core or extras, they do a test install on a system with what amounts to every possible package installed, simultaneously. If that package causes conflicts, (overwrites files, introduces a new library version, clobbers a configuration file, tries to listen on a port being used by an existing service) then it gets thrown back to the maintainer who is told to fix it.
By building up a distribution in this fashion, you can guarantee that no particular package interferes with another.
It's the fucking principle of mathematical induction. It's not hard to understand.
What you're trying to address are the concerns of predictability. Will a user who downloads un-officially-packaged XYZ have a system with the right requirements to run XYZ?
It used to be bad. Nowadays I can't remember the last time I ran into issues with 3rd party SRPMS or RPMS. If it says "RHEL 4+ or Fedora (recent)" on the download, its gold. Chalk it up to stable package naming or whatever.
If it wants something I don't have, I just copy and paste it into yum. It's not exactly rocket science.
It would be nice to have feature baselines with names that are agreed upon by the community. In this fashion you can install a "metapackage" which ensures all the required features are available and also checks for blacklisted packages that may change behavior in an unsupported way.
Frankly, just a list of libraries/APIs and version number ranges would be enough.
1) By your logic, for every piece of software I could install on a Windows machine (Q), there are 2^(Q-1) configurations to validate if I'm testing my specific product.
2) The codebase is anything but monolithic. Windows is monolithic. The divisions between packages are designed to minimize the stepping-on-of-toes while simultaneously maximizing component reuse. Solaris has a few thousand packages in its OS too, and you can configure that quite discretely. So what makes linux any different?
3) Debian isn't taking responsibility for the Mozilla codebase anymore than it takes responsibility for the linux kernel or glibc. They want to have the option to distribute packages and patches as they see fit (so that they can fully integrate them into the package management distribution system), incorporate distribution-specific patches that address the needs of the Debian userbase, etc.
People who use distributions are downloading packages from the distribution because they know the maintainers are doing the localizations, putting files and menus in the right places, and making sure that the installation isn't going to clobber a library file (like many a package in a certain closed source OS is wont to do). If they get a security alert in their email from the distribution, they know they can just run a single update command and all managed, relevant packages will be patched to address the concern.
Legal responsiblity doesn't enter into it anywhere. Maybe you missed the copious CAPSLOCKED warnings (from both Mozilla and Debian) in the readmes that warn of the lack of any warranty or usability guarantees.
It's just Mozilla doesn't want them to touch the source code and still call it Firefox. That's all. Most distributions do something like call it "web browser" or something similar (even if the package is named "firefox"). Debian is taking it a step further, having looked closely at the trademark agreements, and is replacing all of the branding with a single patch so that Mozilla couldn't stop anyone from using the GPL'd codebase as they saw fit.
Mozilla.org is being kinda silly. I hope that they address the issue soon... the Sun/OpenOffice.org foundation doesn't have this issue with branding and logos.
The only reason why anyone would deploy Citrix is to deploy a Windows application on a large scale. It's rather trivial with Unix (pick from one fifty different approaches, with varying levels of cost, complexity, scalability, and done-for-you-ness)
Yeah, and we'll plug that 50 Tbps fiber into our optical quantum computer.
Let's face it, you have to convert to/from copper eventually; fiber is only good for modulating multiple carriers and going long distances. No single channel is going to pass any more than 10Gbps because there isn't an IC out there now or five years from now that can do anything with it.
of working in an organization where you have little interdependancy between offices.
Our teams are spread out over the eastern seaboard, and our employees are often on travel at customer sites, so we have to centralize as much as possible to keep everything accessible and to keep everyone in touch. We have to cluster/failover critical resources and intra-campus links.
I know a lot of large organizations have these issues, so sometimes you really do need a datacenter prima donna if you want to keep your employees and customers happy.
Nvidia supplies the source to an interface module. This module is linked against the kernel, and then it links in a seperate binary blob that lets the rubber meet the road.
Also, loading it taints your kernel. This means nobody is allowed to distribute the combination of linux kernel + NVidia driver in the kernel module tree, strictly speaking. That's why you have to jump through a few hoops to get it installed.
It isn't (technically) the best fighter out there for tournament play or anything. Itstead you've got a grab bag of all your favorite avatars and silly special effects. Mash mash mash, drink some beer, mash mash mash, repeat, etc.
The codebase is very old, contains a bunch of legacy stuff nobody really understands, as the codebase has passed hands from a German company to Sun to the OpenOffice.org foundation. It's also picked up a layer of java along the way (for whatever reason).
It's too bad because it actually works kinda okay, but it's a real effort to get your hands dirty with. Blender is also like that... it seems when a codebase has 'gotten around' it tends to pick up the bad habits of all the hands its been through.
MySQL is a bad state because it's really only developed by MySQL AB -- no one else is contributing to it so they have no reason to make it any more maintainable than it is. PostgreSQL, on the other hand, had the luxury of being the fruit of some academic research projects and was rewritten once or twice, so it's a little more maintainable.
Kind sir! I did not intend that one would use a switching device that merely buffered signals to an output bus. I would hope that one would use a device that has compensation, or at the very least switches during a blanking interval (if your multiple sources come from the same card, they will probably use the same clock).
As for the software, there are many ways one could start playback on a hidden surface and switch the viewport (or z-order or some other technique). Most of them require some sort of application programming to encode such behavior. But I was trying to think of ways that simplify the software component (using existing tools) and rely on the known behavior of some hardware which is a fixed cost.
TITLE = No Hay Problema ARTIST = Pink Martini GENRE = ROCK ALBUM = Sympathique TRACKNUMBER = 2 DATE = 1997 COMPOSER = Jacques Marray
And did you know: OOBE stands for "Out Of Box Experience", not "Out Of Body Experience" There's a bunch of weird little installer-type things in there.
Anything can wake itself up at specific time... it could just be a perl script.
But you really do want at least 1 seperate screen for this, and two extras are better. It's difficult to get a video stream to "start" onscreen without a pause or video glitching programmatically unless you are going to (lets say) write a full-blown, multi-threaded QuickTime application. And I don't think that's necessary.
With two screens you accomplish a cut in a hardware device that you can use for other things too (say playing a VHS cassette, patching in a live feed, allowing input from backup servers without recabling, etc.)
Redirecting audio is as simple as ensuring you have a dedicate sound device for video playback and use that target in all your video playing software commands. Realistically, in a server environment, there aren't any other sounds. Just use the default/onboard device if its halfway decent.
The whole "accidentally switching over with your mouse" thing is a real problem that needs to be directly addressed.
This is what you need:
*) At least one seperate video card monitor output per video channel (Matrox Gxxx, NVidia MVS 440) *) A decent scan-line converter to convert and interlace the VGA into NTSC (one per sim. channel) *) Ideally, a programmable, matrixed video switch.
With a decent 3U server you can stuff in a few PCI or PCIe cards and handle 4-7 channels simultaneously on one box without framedrops.
You're going to need to fiddle with your X configuration until you (at least) have a seperate screen per monitor. Disable your core pointer and input handling on the non-console X servers. Make sure to set the vertical frequency to 59.94 Hz so that you don't get flicker or tearing. Set the backdrop of each screen using xsri/xsetroot to an image to the effect of "Technical Difficulties, Please Wait" in case a playback program crashes or fails to launch.
Then what you do is manually launch fullscreen versions of (mplayer, vlc, whatever) in response to program events on an 'open' screen. Then you switch the matrix so that the VGA channel you just started a new video stream on, and send that to the scan-converter (and the rest of the broadcast stack).
You could (automatically, manually) script of all of this. I could imagine a cron job that wakes up at 15 second intervals to parse a configuration file that sort of encodes the days schedule -- starttimes, running times, intro padding time, which output channel to direct the matrix switch to, filenames or pointers to directories containing ad segments of various lengths, whatever. You purposefully allow playback overlap, at which point the script would just allocate a new video channel to run the new video in, and issue a matrix switch so the video looks like it just cuts from one segment to the next at the appropriate time. When the running time is reached (or the player exits at the end of playback), it "reclaims" the channel so new videos can be run there. You can manually assign input and output channel numbers instead of worrying about having the script keep track (or get the schedule entry app to do it for you).
Uh... that's supposed to happen. The Deny All on the alias is checked first (permissions on each level of alias redirection must succeed before the final directory check). It never even attempts to look for the directory with Allow All since the Alias failed early.
So you get 403 instead of 404. And if you think about it, it makes sense.
By creating an alias you are asserting you intend to service a virtual path. Whether or not what it points to exists is immaterial, since the contents of the path can be realized in many different ways (modules, further alias redirects, CGI, handlers, filesystem). A failure to access the alias via ACL should result in the 403... you don't want to leak the validity of the path (or existance of any real or virtual resources under that path) to a remote user.
404 is an indicator to an end user that a resource they _should_ be able to access is not available at the path specified... completely different. It is not intended to directly reflect the presence or absence of an inode on the host filesystem.
Purchase a bunch of simple RJ45 "protective caps" or covers and use them in all of the unused outlets in the room. You could then modify one of the caps to contain the microphone without looking out of place.
JavaScript _should_ be multithreaded in the browser. The interpreter core appears to allow for threadsafe contexts (last time I checked out Spidermonkey) but what hasn't happened is someone creating a wrapper/hook around pthreads (or whatever) to allow for spawning new contexts and syncronization between threads.
I really think this needs to happen very soon. It's already a pain working around the blocking nature of event handling in the current implementations of JS.
You could always tell when a wall was going to recess into the ceiling... typically you are in a dead end area and take a long hallway with lots of 'columns' (which actually are framing a wall) and the lighting 1) doesn't match up 2) is just black. And the spawn areas... any room that was relatively open and devoid of monsters when you first enter it.
Of course, you can always find a way to make it more interesting.
What I like to do is 'F5' before entering a large space. Then run in and try to trigger as many spawns or aggro as many hidden enemies as possible. Do your best to off them, and check your health/ammo. Then F9 and try again. This time, try to get off without a scratch (or just enough to be covered by health/shards you passed earlier).
It's like a dance. Boom, jump, headshot, pump, duck, headshot. 'F5'
I was starting every map with 125/100 all the way up until Hell on Veteran.
Someone who qualifies the seriousness of their application by the number of threads it uses is severely misguided.
Real applications manage thousands of asyncronous activities without needing thousands of associated threads and task switching overhead. You use one process per "concern" per core (where applicable) and service as much as you can, as fast as you can, and just run like a freight train down through your priority queue.
Sigh. I was thinking the same thing last week.
on
GUIs Get a Makeover
·
· Score: 1
And I mean, that's why the USB HID standard exists. A buttons-n-dials type hardware interface should just appear as an undifferntiated joystick-like input device. So to test user software you can hook up any $30 USB joystick and plug it in, and your OS should enumerate all the axises, sliders and buttons.
Alas, there's no simple way to register variables with an always-active interface like that.
The application has to specifically want to have certain variables modified in such an arbitrary fashion. And few developers have the time or patience to, on top of everything else, hook up a Gravis gamepad and negotiate the game-centric APIs that Windows provides to get access to these generic interface devices. And make sure that the sliders n' whatnot get priority mapped to whatever setting is currently most important (or possible to change), and that it can change in realtime.
There are some realtime performance applications that let you do this (all of them that I know are audio/video DJ apps)... typically you map a mouse axis, or a joystick axis, or a midi event trigger to some internal variable that can be continiously controlled. You ususally have a subdialog where you have a "realtime modify this parameter" checkbox or whatnot, at which point it pops up a dialog which prompts you to wiggle the input dohick you want mapped to it, warn you if there's a conflict, and then to calibrate it.
But I would have trouble consistently when docking and undocking. I had an HP Omnibook and a Dell Latitude, and I had trouble with both with that issue. It wouldn't happen all of the time, only some of the time. For example: the docking bay CD drive would randomly fail to be detected. Or it would fail to switch from the onboard networking controller to the one in-dock.
I gave up and installed linux on the omnibook. That worked surprisingly well if I didn't try to use ACPI. APM suspend/hibernate and dock/undock was solid.
Now I use an IBM X31 with 2003 and Fedora 4 (using ACPI, not APM !). Never had a problem with power related or docking related issues with that at all. It took the OEMs and the OS vendors long enough.:-(
Slashdot Mirror
You know, uh, when someone like Fedora wants to test a package before accepting it into say, core or extras, they do a test install on a system with what amounts to every possible package installed, simultaneously.
If that package causes conflicts, (overwrites files, introduces a new library version, clobbers a configuration file, tries to listen on a port being used by an existing service) then it gets thrown back to the maintainer who is told to fix it.
By building up a distribution in this fashion, you can guarantee that no particular package interferes with another.
It's the fucking principle of mathematical induction. It's not hard to understand.
What you're trying to address are the concerns of predictability. Will a user who downloads un-officially-packaged XYZ have a system with the right requirements to run XYZ?
It used to be bad. Nowadays I can't remember the last time I ran into issues with 3rd party SRPMS or RPMS. If it says "RHEL 4+ or Fedora (recent)" on the download, its gold. Chalk it up to stable package naming or whatever.
If it wants something I don't have, I just copy and paste it into yum. It's not exactly rocket science.
It would be nice to have feature baselines with names that are agreed upon by the community. In this fashion you can install a "metapackage" which ensures all the required features are available and also checks for blacklisted packages that may change behavior in an unsupported way.
Frankly, just a list of libraries/APIs and version number ranges would be enough.
1) By your logic, for every piece of software I could install on a Windows machine (Q), there are 2^(Q-1) configurations to validate if I'm testing my specific product.
2) The codebase is anything but monolithic. Windows is monolithic. The divisions between packages are designed to minimize the stepping-on-of-toes while simultaneously maximizing component reuse. Solaris has a few thousand packages in its OS too, and you can configure that quite discretely. So what makes linux any different?
3) Debian isn't taking responsibility for the Mozilla codebase anymore than it takes responsibility for the linux kernel or glibc. They want to have the option to distribute packages and patches as they see fit (so that they can fully integrate them into the package management distribution system), incorporate distribution-specific patches that address the needs of the Debian userbase, etc.
People who use distributions are downloading packages from the distribution because they know the maintainers are doing the localizations, putting files and menus in the right places, and making sure that the installation isn't going to clobber a library file (like many a package in a certain closed source OS is wont to do). If they get a security alert in their email from the distribution, they know they can just run a single update command and all managed, relevant packages will be patched to address the concern.
Legal responsiblity doesn't enter into it anywhere. Maybe you missed the copious CAPSLOCKED warnings (from both Mozilla and Debian) in the readmes that warn of the lack of any warranty or usability guarantees.
It's just Mozilla doesn't want them to touch the source code and still call it Firefox. That's all. Most distributions do something like call it "web browser" or something similar (even if the package is named "firefox"). Debian is taking it a step further, having looked closely at the trademark agreements, and is replacing all of the branding with a single patch so that Mozilla couldn't stop anyone from using the GPL'd codebase as they saw fit.
Mozilla.org is being kinda silly. I hope that they address the issue soon... the Sun/OpenOffice.org foundation doesn't have this issue with branding and logos.
the binary and launch scripts still say "mozilla".
the cost of the power to run that thing is more than its computing throughput is worth.
The only reason why anyone would deploy Citrix is to deploy a Windows application on a large scale. It's rather trivial with Unix (pick from one fifty different approaches, with varying levels of cost, complexity, scalability, and done-for-you-ness)
Yeah, and we'll plug that 50 Tbps fiber into our optical quantum computer.
Let's face it, you have to convert to/from copper eventually; fiber is only good for modulating multiple carriers and going long distances. No single channel is going to pass any more than 10Gbps because there isn't an IC out there now or five years from now that can do anything with it.
of working in an organization where you have little interdependancy between offices.
Our teams are spread out over the eastern seaboard, and our employees are often on travel at customer sites, so we have to centralize as much as possible to keep everything accessible and to keep everyone in touch. We have to cluster/failover critical resources and intra-campus links.
I know a lot of large organizations have these issues, so sometimes you really do need a datacenter prima donna if you want to keep your employees and customers happy.
Nvidia supplies the source to an interface module. This module is linked against the kernel, and then it links in a seperate binary blob that lets the rubber meet the road.
Also, loading it taints your kernel. This means nobody is allowed to distribute the combination of linux kernel + NVidia driver in the kernel module tree, strictly speaking. That's why you have to jump through a few hoops to get it installed.
It isn't (technically) the best fighter out there for tournament play or anything. Itstead you've got a grab bag of all your favorite avatars and silly special effects. Mash mash mash, drink some beer, mash mash mash, repeat, etc.
The codebase is very old, contains a bunch of legacy stuff nobody really understands, as the codebase has passed hands from a German company to Sun to the OpenOffice.org foundation. It's also picked up a layer of java along the way (for whatever reason).
It's too bad because it actually works kinda okay, but it's a real effort to get your hands dirty with.
Blender is also like that... it seems when a codebase has 'gotten around' it tends to pick up the bad habits of all the hands its been through.
MySQL is a bad state because it's really only developed by MySQL AB -- no one else is contributing to it so they have no reason to make it any more maintainable than it is. PostgreSQL, on the other hand, had the luxury of being the fruit of some academic research projects and was rewritten once or twice, so it's a little more maintainable.
Kind sir! I did not intend that one would use a switching device that merely buffered signals to an output bus. I would hope that one would use a device that has compensation, or at the very least switches during a blanking interval (if your multiple sources come from the same card, they will probably use the same clock).
As for the software, there are many ways one could start playback on a hidden surface and switch the viewport (or z-order or some other technique). Most of them require some sort of application programming to encode such behavior. But I was trying to think of ways that simplify the software component (using existing tools) and rely on the known behavior of some hardware which is a fixed cost.
TITLE = No Hay Problema
ARTIST = Pink Martini
GENRE = ROCK
ALBUM = Sympathique
TRACKNUMBER = 2
DATE = 1997
COMPOSER = Jacques Marray
And did you know: OOBE stands for "Out Of Box Experience", not "Out Of Body Experience"
There's a bunch of weird little installer-type things in there.
Anything can wake itself up at specific time... it could just be a perl script.
But you really do want at least 1 seperate screen for this, and two extras are better. It's difficult to get a video stream to "start" onscreen without a pause or video glitching programmatically unless you are going to (lets say) write a full-blown, multi-threaded QuickTime application. And I don't think that's necessary.
With two screens you accomplish a cut in a hardware device that you can use for other things too (say playing a VHS cassette, patching in a live feed, allowing input from backup servers without recabling, etc.)
Redirecting audio is as simple as ensuring you have a dedicate sound device for video playback and use that target in all your video playing software commands. Realistically, in a server environment, there aren't any other sounds. Just use the default/onboard device if its halfway decent.
The whole "accidentally switching over with your mouse" thing is a real problem that needs to be directly addressed.
This is what you need:
*) At least one seperate video card monitor output per video channel (Matrox Gxxx, NVidia MVS 440)
*) A decent scan-line converter to convert and interlace the VGA into NTSC (one per sim. channel)
*) Ideally, a programmable, matrixed video switch.
With a decent 3U server you can stuff in a few PCI or PCIe cards and handle 4-7 channels simultaneously on one box without framedrops.
You're going to need to fiddle with your X configuration until you (at least) have a seperate screen per monitor. Disable your core pointer and input handling on the non-console X servers. Make sure to set the vertical frequency to 59.94 Hz so that you don't get flicker or tearing. Set the backdrop of each screen using xsri/xsetroot to an image to the effect of "Technical Difficulties, Please Wait" in case a playback program crashes or fails to launch.
Then what you do is manually launch fullscreen versions of (mplayer, vlc, whatever) in response to program events on an 'open' screen. Then you switch the matrix so that the VGA channel you just started a new video stream on, and send that to the scan-converter (and the rest of the broadcast stack).
You could (automatically, manually) script of all of this. I could imagine a cron job that wakes up at 15 second intervals to parse a configuration file that sort of encodes the days schedule -- starttimes, running times, intro padding time, which output channel to direct the matrix switch to, filenames or pointers to directories containing ad segments of various lengths, whatever.
You purposefully allow playback overlap, at which point the script would just allocate a new video channel to run the new video in, and issue a matrix switch so the video looks like it just cuts from one segment to the next at the appropriate time. When the running time is reached (or the player exits at the end of playback), it "reclaims" the channel so new videos can be run there.
You can manually assign input and output channel numbers instead of worrying about having the script keep track (or get the schedule entry app to do it for you).
Uh... that's supposed to happen.
The Deny All on the alias is checked first (permissions on each level of alias redirection must succeed before the final directory check).
It never even attempts to look for the directory with Allow All since the Alias failed early.
So you get 403 instead of 404.
And if you think about it, it makes sense.
By creating an alias you are asserting you intend to service a virtual path. Whether or not what it points to exists is immaterial, since the contents of the path can be realized in many different ways (modules, further alias redirects, CGI, handlers, filesystem). A failure to access the alias via ACL should result in the 403... you don't want to leak the validity of the path (or existance of any real or virtual resources under that path) to a remote user.
404 is an indicator to an end user that a resource they _should_ be able to access is not available at the path specified... completely different.
It is not intended to directly reflect the presence or absence of an inode on the host filesystem.
someone just got kicked from LUE links.
Purchase a bunch of simple RJ45 "protective caps" or covers and use them in all of the unused outlets in the room. You could then modify one of the caps to contain the microphone without looking out of place.
a p/image/img.jpg
http://www2.elecom.co.jp/cable/accessory/ld-rj45c
Mischa works for Six Apart _because_ Bantown "pwnzed" them two years back.
Six Apart didn't try to fight them, instead they tempted them with guided tours and positions in the company.
Utter idiocy.
I never knew there was a requirement for Ajax to interface with J2EE on the server!
And here I am using Perl and Ruby like an idiot.
JavaScript _should_ be multithreaded in the browser.
The interpreter core appears to allow for threadsafe contexts (last time I checked out Spidermonkey) but what hasn't happened is someone creating a wrapper/hook around pthreads (or whatever) to allow for spawning new contexts and syncronization between threads.
I really think this needs to happen very soon. It's already a pain working around the blocking nature of event handling in the current implementations of JS.
You could always tell when a wall was going to recess into the ceiling... typically you are in a dead end area and take a long hallway with lots of 'columns' (which actually are framing a wall) and the lighting 1) doesn't match up 2) is just black.
And the spawn areas... any room that was relatively open and devoid of monsters when you first enter it.
Of course, you can always find a way to make it more interesting.
What I like to do is 'F5' before entering a large space. Then run in and try to trigger as many spawns or aggro as many hidden enemies as possible. Do your best to off them, and check your health/ammo.
Then F9 and try again. This time, try to get off without a scratch (or just enough to be covered by health/shards you passed earlier).
It's like a dance. Boom, jump, headshot, pump, duck, headshot. 'F5'
I was starting every map with 125/100 all the way up until Hell on Veteran.
Someone who qualifies the seriousness of their application by the number of threads it uses is severely misguided.
Real applications manage thousands of asyncronous activities without needing thousands of associated threads and task switching overhead. You use one process per "concern" per core (where applicable) and service as much as you can, as fast as you can, and just run like a freight train down through your priority queue.
And I mean, that's why the USB HID standard exists. A buttons-n-dials type hardware interface should just appear as an undifferntiated joystick-like input device. So to test user software you can hook up any $30 USB joystick and plug it in, and your OS should enumerate all the axises, sliders and buttons.
Alas, there's no simple way to register variables with an always-active interface like that.
The application has to specifically want to have certain variables modified in such an arbitrary fashion. And few developers have the time or patience to, on top of everything else, hook up a Gravis gamepad and negotiate the game-centric APIs that Windows provides to get access to these generic interface devices. And make sure that the sliders n' whatnot get priority mapped to whatever setting is currently most important (or possible to change), and that it can change in realtime.
There are some realtime performance applications that let you do this (all of them that I know are audio/video DJ apps)... typically you map a mouse axis, or a joystick axis, or a midi event trigger to some internal variable that can be continiously controlled. You ususally have a subdialog where you have a "realtime modify this parameter" checkbox or whatnot, at which point it pops up a dialog which prompts you to wiggle the input dohick you want mapped to it, warn you if there's a conflict, and then to calibrate it.
:3
But I would have trouble consistently when docking and undocking.
:-(
I had an HP Omnibook and a Dell Latitude, and I had trouble with both with that issue. It wouldn't happen all of the time, only some of the time.
For example: the docking bay CD drive would randomly fail to be detected. Or it would fail to switch from the onboard networking controller to the one in-dock.
I gave up and installed linux on the omnibook. That worked surprisingly well if I didn't try to use ACPI. APM suspend/hibernate and dock/undock was solid.
Now I use an IBM X31 with 2003 and Fedora 4 (using ACPI, not APM !). Never had a problem with power related or docking related issues with that at all. It took the OEMs and the OS vendors long enough.