I wonder how long it'll be before someone writes a random serial number generator for these things, and people who haven't even heard of a modchip start getting bumped because someone else impersonated them.
I'm sure there are a lot of possible numbers, and the chances of someone hitting a correct serial key before Microsoft boots 'em for too many connections'd be pretty rare, but still.. all it takes is one legit game coder who does something stupid and uses that serial key as a unique user id number in a network game, and bye bye security. All it would take is some smart fellow with a packet sniffer to get that value, and suddenly it isn't safe to play against people you don't know because they might steal your xbox's serial key...
Okay, so it ain't gonna happen all that often. *cough*.. Am I missing something? They've got this pretty well thought out, don't they?
My guess is that some moderator thought that asking on the availability of a package is automatically an insult. To all moderators; if they aren't explicitly being insulting, then it's probably a genuine question! It's pretty sad when our hides get so thick that our immediate answer to a request for help is to try and ignore them.
To answer the original question, my guess is that it'll probably go into the latest unstable, which is Sid. (If it isn't in there already.) My guess is that it's probably not going to be around long enough to make the testing release, Sarge, before Sarge gets bumped to stable. From what I understand, to make Sarge, it'd need to be in for 3 months. If they bump Sarge to stable in less than 3 months, it won't make the next stable release. I could be wrong, here, though.
I don't personally run Debian anymore (Windows), so.. maybe someone from Debian could offer some insight here, on just how much work needs to be done to get this hooked in with the latest X, and what it would take for it to make it into Sarge.
Thanks for the tips!:) I did some research to check each of these out.
I think that's what XRender does. - How closely related are XRender and XAA? Is there a central repository of all of these extensions, and to what degree they've been accepted/supported by different tk's?
MS TrueType fonts and Xft. - Why are we still depending on Microsoft for our font needs? How many fonts are there out there that aren't from Microsoft, or Corel or other proprietary companies, and still look decent enough to use in prefessional reports, etc.? How many decent free fonts are there available out for other languages, such as Japanese, Chinese, etc.? Is there a free font creation project anywhere? More importantly, is there even a free program out there for creating Truetype fonts?
X clipboard mechanism standard - According to the article, the clipboard one allows for the cut/paste of ASCII data. What about image or audio data?
GNOME Clipboard Manager - Why does this expose the different X-level parts of the clipboard to the user? All I should see in a clipboard manager is what I've copied in the past. Not COMPOUND_TEXT, ATOM_.. etc.
You run DRI apps as root?! *gasp* Why can I run Tuxracer as normal user?
*grin* Withdrawn.:) Last time I ran Linux, if I wanted to do anything 3D that changed the screen to fullscreen, I had to be root. I take it this has since changed.
XEmbed. Work in progress.
Kickass!
BlueCurve and Keramik/Geramik provide a consistent look for both toolkits.
Ah. Is this a consistant look, though, or a consistant back end? What I'd like to see is a standardized back-end component that both link against for their theming capabilities, so that people can just target that one lib and have changes to themes for it change all of your desktop tk's.
The advantage I see, in these newer projects, is that they're willing to say "here, there are the objects you can use. If you want something new, build it out of these, but for basic stuff, this is what you use." It allows them to abstract out the simple stuff, so that stuff that should be run on the X server anyways can be.
An example of what I mean is a window manager set up to follow mouse focus. If I'm sitting at a box, and I move my cursor across the screen, each time I enter/exit a window, the focus changes. X kicks in, sends a message to the client, and the client updates the window to visually show that it's now got the focus. If I'm accessing a remote machine when I'm doing this, it can be slow as heck just to move the pointer across the screen.
The advantage of these newer kits is that stuff like this is all done on the server end. If it's just dumb interface stuff, the client doesn't even have to really worry about it. This results in reduced network traffic and reduced latency where it really matters; when the user is using the system.
Or is there a server-side window managing / toolkit access extension already out there for X that I don't know about? ^_^;
Window transparency, maybe not, but how about object transparency? Instead of text selection requiring a repaint of the entire text, with a different background colour, why not send just one transparent tinted box over the network instead?
I'm sure if you think about it, you can come up with several other useful applications of something like this.
Things I think X needs, really quickly:
decent fonts
better cut and paste, with a memory, and perhaps a history stack
further separation of X's core from X's drivers. Standardized drivers so that any other application can use them--ie, so we don't NEED to use X. (I'm talking about the XFree86 implementation, here, mostly.)
make it so I don't have to run DRI programs as root. Heck, get rid of running anything in X as root; anything that needs to be root should be a kernel driver, or a userland resident program.
standard widget set, and a standard 3rd party widget registry, so GNOME and KDE widgets can co-exist in the same application, or at least access eachother through a standard communications channel. (you laugh..)
I wrote this yesterday. Please correct me (this post and that) where I'm wrong; I really do want to understand this stuff as best I can.
I wholeheartedly agree. Function argument completion alone is why I stick to Windows for all my development work. Give me a GNOME or KDE IDE that also:
features an integrated debugger
has help files, for the function whose name my cursor's currently over, that load with the touch of one key
contains a project manager on the left that crafts my makefiles for me, and allows for drag and drop rearranging of my project's files
shows me all my classes in my project, in a derivation tree, and what it inhereits and from whom
works
..and hey, I'll come back. Until then, though, a Visual Studio bitch I'll remain.
It's not that they don't look and feel the same. I personally think there's a more fundamental problem, and that problem is X.
X was designed, from the start, to be a low-level API to allow different types of UNIX windowing systems to interoperate. It was designed to be quick on the hardware of that day, which was monochrome or paletted, and speedy across network connections like 300 baud. It was designed with the intention of people writing cheap toolkits for it, toolkits like Motif, that were low-bandwidth.
Now why did they go with the client-side toolkit idea? There are a few reasons. One is because the target machine wasn't always of the same architecture, and porting the library to another architecture could be a pain. Another is that it took more bandwidth to transfer the library to the user's side than it did to just send the basic drawing instructions.
Nowadays, we have two solutions to the first problem; we can either use a VM to run our libraries, or we can just compile it for them. (This is where Autoconf, Automake and libtool come in handy.) Worse comes to worst, we can have a fallback that uses an X remeniscient remote painting facility, if they don't have the tk installed.
The second problem is obsolete. Toolkits are now being themed, which means that we have huge numbers of image files being used to "paint" interfaces. If the machine that's the X server isn't the same as the X client, then these images are painted on the client and sent over the network to the server. Eek. Also, these are typically images that aren't natively supported by X (X only supports paletted images) so we need to use an extension, so programmers have some cruft to worry about, here, too. (ie; What if the extension's supported, but poorly, and it fails halfway through the call?)
Now don't tell me that we need to do things this way, because we don't. In the latest release of Windows, XP now has that level of network transparency. If you want to access your home computer's apps from work, it's as simple as logging into it from work. Instantly, your home drives appear in your explorer, and you can access windows on the screen of your home box.
Now why am I making such a big deal about this, you ask? Well, it's because they're not just taking a screenshot of the desktop and sending it. They've taken a page from X's book, and they send the higher-level commands over the network. Essentially, GDI calls. And, from what I understand, you end up with a consistant interface on the accessing end, because it uses the accessor's theme set.
Now this is just my rant about X's networking components. If you want to get into XFree86, I can tell you that I'm not at all pleased with the way they've set it up. X should not be the video driver. When I start my machine, I should not have to load X in order for my graphics card driver to be loaded. It should be loaded, waiting and ready to be accessed, by any application.
The way I see it, the system should come up by loading the graphics driver. It should be a process that's always running. Then there should be a standard library through which anyone can access the graphics driver. The card's state should be in the driver, not X! The driver should be in charge of the card, not X! X should be just another application that people can run to get a windowing environment.
The closest I can find to this idea, right now, is the libGGI/libGII/kgi people. They've got a basic framework for their API down, but it only works with a limited number of cards, and only one of those uses acceleration features so far. If that API were expanded for full 3D support, and a few more recent cards could be added to that list, or bumped up to full acceleration, I think we'd all be a lot better off. Heck, they've already got an Xggi server written--they've had it for years.
As for X on the desktop, GNOME had to hack a CORBA ORB to get the functionality that Windows provides for free. For X, the lack of standardization in the 3rd party object components department has been a huge pain in the ass for anyone interested in combining a KDE part with a GNOME widget in the same program. You end up having to port one of them the other way. If X could be made to have it's own object tracking extension, that would help bandaid the solution, but I think it's just a symptom of a much bigger problem.
X is old. It shows. We need something new; I say make X a plugin for whatever new windowing system we use tomorrow, and that we get started on making that new one soon.
If we want to put a GNU system on every desktop, X as the windowing system just isn't the right solution anymore.
I used Linux for a little over a year, three years ago. Several reasons forced me back to Windows, one of which was the need to have Visual Studio, but now that I'm a student again, there are still several things keeping me from going back:
Virtual Dub - Linux has no equal for manipulation of.AVI files. It has no Premiere either, but let's not even go there..
Cubase - Linux has no equal here either. (Installing five different packages of something so I can use something half written in Tcl/Tk and using Motif for a GUI doesn't count.) Likewise, show me how I can load my MIDI soundfonts for my Audigy under Linux automatically with every boot, without having to hack a boot script or cron job. (Or are soundfonts for MIDI even supported under Linux? Last time I checked they weren't..)
Hardware support - ATi Radeon 8500LE is not supported for 3D under Linux. Given as my main field of interest is 3D graphics, and I play with shaders all the time, there's no way in hell I'm going back without this.
Webcam - USB, and not supported under Linux. I'm not going to shell out for another one.
TV Tuner - Hauppauge, but just way too much work to set up under Linux. Would my remote control still work? If not, forget it.
Document support - Can you import PowerPoint files yet? One of my prof's notes are exclusively in those.
CDR burning - Does your burner app support.cdi and.nrg image file formats?
Games.
And now the biggie--X. I hate it. My reasons:
- It's not the OS, already, get over it. It shouldn't run as root, and it shouldn't be required for advanced graphics support. If someone wants to write a driver for a card, they shouldn't need to target DRI/DRM for best speed. If libGGI and KGI or something similar became the lowest level entry point for graphics, I'd be more than happy to switch back. But as long as X is calling the shots, I'm not interested.
- The interface is not centralized/standardized. Yes, I know why, but that's not why most people who'd use it on the desktop would use it today. (OSes whose interfaces I do like; BeOS, MacOSX.. Heck, even Windows is kinda nice. With Windows XP, you now have network transparency, and quicker than X, too. I think it's time to rethink this one.)
- I need Japanese entry support. Compared to the Microsoft IME, the X entry method is a turd, and a pain to toggle on/off, depending on the application. I'm either logged in in Japanese, or in English; there's no way to have Japanese entry with an English interface. Likewise, behaviour varies from toolkit to toolkit. Crap.
- GNOME is a dog. If you turn up it's settings so that visually, it's halfway acceptable, your speed drops to half, as things that modern video cards can compute easily are done on the CPU. Under Win2k, my Radeon 8500LE cheats, using it's 3D acceleration capabilities to help accelerate transparent objects, from dragged objects to windows to text.
- Windows has more useable fonts available out of the box, period. I don't care if X has more; if it looks like someone spat on the screen, I ain't usin' it.
No, it's because some of these planes are old, from way before cellphones quite as ubiquitous as they are now. They didn't have as strict of regulations concerning electrical signals back then, so some of the electronics in the older planes aren't shielded against the frequencies used by cellphones.
Rather than having different rules for different planes, and all of the confusion that comes from it, there's a blanket rule against cellphone usage. Makes things easier. For everyone.
I'm curious how one could program games to take advantage of the latter. Perhaps you know something about the OpenGL and Direct3D specs that I don't?
Direct3D currently does texture caching on it's own whenever you (as a programmer) choose to use "managed textures." If you try to run a (DirectX) game made for 64 megs on a 32 meg card, that hit you take is, more often than not, the textures swapping into "cache" every frame. Since any game programmer worth his salt has already optimized his engine to minimize texture set calls, you shouldn't often run into the situation where you're swapping the same texture in and out again. (Unless, of course, you need to render a lot of transparent textures, in which case you're screwed, since they all have to be rendered in Z-order. So even if some are the same, they can't be grouped. But I digress.)
In OpenGL, you can do caching too. You're just forced to do it all yourself. This can be helpful, because then you can tune the caching algorithm yourself... but then again, you can write your own caching system for Direct3D too, if you want, so it's not really a notch in OpenGL's favour not having this feature..
Here's a little tip; the big difference between ATi and nVidia cards for most games isn't the raw power of the card. No, it's the time spent making state changes. (That includes texture changes.) ATi cards are notoriously bad for running at one third of optimal if you don't optimize (and by optimize, I mean group 'em to minimize 'em) every single state call in your engine. nVidia just writes faster state change code; that's why their cards seem faster.
Not that this should really surprise most people. ATi's never been really renowned for their drivers. But it's just one of those things that can be really damaging. Especially when an engine programmer makes the assumption that hey, it doesn't matter if we set all these render states, the driver will optimize out those that aren't needed, and, lo and behold, ATi's don't..
Now mind you, I haven't played with a 9700. You never know; the times, they may be a changin'. But the 8500 drivers had this, and every card before it from them that I can remember.
... Furthermore, placing the RM/RMC register on the stack is an impossibility without breaking backward compatibility; many assembly language coders depend on a set number of bytes being added to the stack when they perform a call or interrupt.
Why not just add 24 GP registers to the existing processor?
Aren't these two observations in conflict with eachother? Last time I checked, PUSHA/POPA still needed to be called in such situations. Unless you're talking about implementing yet another PUSHA/POPA extension instruction to go along with the new registers..
So yes, your solution would be possible, but you would need to add this instruction with it too, as a bare minimum.
The reason that he's proposing the remap, as opposed to just adding registers, is so he can keep on only using certain registers for certain tasks. Adding new registers means having to rewrite the old instructions so that they can use the new registers. Which means adding new opcodes to the list to support these different versions of the basic opcodes. Which I would see as being an absolutely insanely large modification to the instruction set.
Btw, both your and his proposals suffer from the problem of opcode re-ordering taking up a lot more of the silicon. Currently, the chip only has to know whether two sources and one destination are going to be defined whenever choosing where to put the instruction in the pipeline. (iirc) If you now have the ability to target other sources/destinations, suddenly all those optimizations you made when you put into silicon that these registers are always source, and this one's always destination, are thrown out the window. (And you want this use-for-any-opcode ability for all 24 of the new registers you propose as well?)
Now keeping these things in mind, what's the point in starting on something like this today, when they have another chip ready to come out in a few months? It just doesn't make any sense, from a business point of view.
One last thing; consider the amount of wasted space in x86 with just the current instructions alone. Every time they've added something new, the number of bytes for one operation's gone up. You want them to add more? Okay, assume it's feasible, and that people don't mind having 8-byte opcodes. What will AMD and Intel say to the prospect of emulating these opcodes in their next gen processors? Assume, for the moment, that the 64 bit processors aren't already taped out/near being taped out; how much of a pain in the ass would retooling the new processors to emulate either of these proposals be?
The real, and only solution, is that these companies get their acts together, quit issuing refreshes of old hardware, and finally give us their next gen chips to play with. Proposing anything else is just pointless. (Unless, of course, the new CPUs completely flop..)
Btw, ianae (I am not an engineer), just a lowly comp sci student, so take this all with a grain of salt. : )
(Just think of the security mechanisms on the X-Box as a challenging chastity belt. Ah, young love..)
Re:Surprising this has not happened with soundcard
on
The Last Days at 3dfx
·
· Score: 5, Informative
Simple; Creative does it with Creative marketing.
The Audigy, for instance, is little more than a gamer's card. Any serious review of the card that you come across on the internet will tell you this, or if you bought it hoping for some advanced features, you'll find it out for yourself.
Here are some examples of this Creative marketing:
- The Audigy does support 24bit/96kHz sound playback, as advertised, but does not actually play it at that. The second it hits the main chip, it's downmixed to 16/44. So while you can play sound at the higher frequency to it, you're not actually going to hear it. (This is what they mean when they plaster 24/96 all over the boxart.)
- The Audigy does not have independant recording and playback volume controls on the line in. If you wish to record something on a TV tuner, for instance, then you'll have to either listen to it while it records, or turn off the global volume on your soundcard. (Or turn off the speakers.) This makes it impossible to use an Audigy in a PVR setup.
- The much-touted sub 100dB SNR is only on playback. On recording, the SNR is much higher.
I haven't been this disappointed in a card since my SB 128 upgrade ran slower than my SB 64. (I suspect the 64 did the soundfonts in hardware; the 128 did them in software.) Looking at the new Audigy 2, it appears that they'll be offering the 24/96 functionality that was insinuated to be present in the original Audigy, but I don't think I'll bite. I think my next card will be a Hoontech.
FYI: They don't wash the lettuce. It comes pre-washed and pre-cut in sealed plastic bags. All they do in the back is pull it out of the bag and spread it on the bun. Likewise all the other junk they put on the product. (It's the same at all of the fast food franchise spots.)
Since they'll have to update OpenSSL anyways, any chance people will move to the new Apache at the same time?
(I doubt it, because most network admins are rightly paranoid--may as well keep the devil you know than expose yourself to the devil you don't. Still.. wishful thinking..?)
There would be if he was growing with seed from a previous year, and it was the previous year's seed that had been contaminated.
What would really suck for this guy would be if his neighbour had been the one "stealing" for a few years beforehand, and if the g.m. stuff had gotten into his mixture back then. He'd have no way to show that the other guy's seed had been g.m.ed, and the other guy sure wouldn't have any incentive to tell anyone about it..
That's like selling you a car saying it has 300HP, but in fact, only has 120.
No, it's more akin to saying it has 300HP, when they're really selling a 120HP engine that's been modified and tuned (but mostly tuned) to run at 280HP.
If you want encrypted IM for over a standard network, you can always give Miranda a shot. Setting up the GNU PG plugin with it can take a little bit of work, but it's possible.
I agree with you, though; something as simple as this should be included right out of the box with every chat client.
If you don't uninstall the old driver set before installing the new one, you can really mess up your system. Likewise if you had a NVidia card previously, and didn't completely uninstall the drivers for that before installing the Radeon ones. Did you upgrade without uninstalling at any time previously? If so, you may want to first unisntall your current drivers, and then pick through the registry for dangling settings from old cards. NVidia's site has a doc describing how to do this for their cards somewhere on their site..
Under Win2k+, ATi's drivers are rock-solid stable. Unless, of course, your motherboard has a lousy AGP driver, in which case you're screwed. (I've found that some motherboard manufacturers only cater to one brand of video card.)
It can be especially bad whenever you have a relatively new motherboard. Some manufacturers ship these things out, and the entire first revision of the board has a flaw. There was a whole generation of VIA chips like this a while back.. I think it was the KT133A chipset on a certain ASUS board.. I had one, but ended up returning it and getting the revision board.
The worst I've had, as far as instability's concerned, with my 8500LE, is a few occassional reboots whenever exiting an especially taxing 3D application. It is a bit annoying, but at least it doesn't lock hard like previous Windows versions did..
Incidentally, if it's your own code that's causing it to reboot/lock up, then I suggest you check your vertex shader setting code. I had a rebooting problem with my own code for a while, and it turned out to be that I was setting an invalid vertex shader. On a NVidia card, it'll just ignore it, and use the fixed function pipeline. On an 8500, the computer'll reboot. Likewise, if it's a specific game that's screwing up on just 8500s, then this could be the problem there as well.
Effects Browser requires that you write the plugin as you usually would, compile, and create a.dll for it, etc., and then you can view it in the Effects Browser. (From the Effects Browser you can't change anything; only view.)
With RenderMonkey, you don't worry about C/C++ at all. All of the settings (constants, input textures, etc.) for the shader are nicely displayed on the left, and you can just click and change them as you wish. This is absolutely nothing like NVidia's Effects Browser.
Maybe the 9700, but the 8500's a whole different monkey. In order to squeeze the extra performance out of the pixel shader, they have a phase instruction which allows the shader to make a second pass, and do dependant texture reads. Something like that'd be hard to compile code to use, I'd wager. At the very least, it'd require the developer know how to tweak Cg code to get it to compile nicely for the 8500, which would probably require they know the assembly-level stuff anyways.
Remember that the 9000 is essentially a modified 8500. They aren't totally getting rid of this architecture yet; they want people to still support it as much as possible. Hence the desire to stick to assembly-level shader coding as long as possible.
Overall, RenderMonkey looks like a nice, useful shader-creation environment for prototyping assembly-level shaders in. All they need to do is add support for OpenGL2's shader language, and Microsoft's, when they come out, and I'm sold.
(And before anyone pipes up that that's Cg, Cg's a totally different product; it's a language, compiler, libraries, etc, but mostly a language spec. RenderMonkey's aiming to be a complete content management system. Cg's for programmers who write tools, RenderMonkey's a tool for your programmers and artists.)
I like the intro. Mind you, I don't watch the show every week, preferring to catch it in reruns, so I don't get a continued and repeated dosage of it. Plus I happen to like country, and I grew up on easy listening, so my tastes are probably vastly different from everyone else's.
This intro's still a million times better than Voyager's, though. That intro theme could put a person to sleep. Actually, come to think of it, it has..
As for the blueprints thing, I wouldn't give them much credit. I'll bet you anything the only reason they're there is (a) because it looks cool, and (b) because Archer's father supposedly designed the ship, and they want to milk that for all it's worth. But mostly I think it's because of (a).
And now for something completely different.
I would like to propose the following; Video Mute. Instead of muting the audio, it would turn the video image contrast down, averaging out the video as much as possible without completely eliminating the video. This would be extremely helpful for whenever I'm watching television and an especially stupid commercial comes on that strobes. every. second. binding. you. (And hey, it might even make music videos watchable.)
Mute + Video Mute would be perfect for those of us who (a) can't afford a Tivo, and (b) want to avoid being distracted by the stupid flashing while we're trying to talk with fellow viewers, or read a book during commercials.
I hereby promise not to patent this idea, and I hereby give everyone in the universe free and unrestricted right to implement and use it, blah blah blah.. or has someone already thought this up and patented it? : )
Slashdot Mirror
I wonder how long it'll be before someone writes a random serial number generator for these things, and people who haven't even heard of a modchip start getting bumped because someone else impersonated them.
I'm sure there are a lot of possible numbers, and the chances of someone hitting a correct serial key before Microsoft boots 'em for too many connections'd be pretty rare, but still.. all it takes is one legit game coder who does something stupid and uses that serial key as a unique user id number in a network game, and bye bye security. All it would take is some smart fellow with a packet sniffer to get that value, and suddenly it isn't safe to play against people you don't know because they might steal your xbox's serial key...
Okay, so it ain't gonna happen all that often. *cough*.. Am I missing something? They've got this pretty well thought out, don't they?
why-oh-why is this a troll?
My guess is that some moderator thought that asking on the availability of a package is automatically an insult. To all moderators; if they aren't explicitly being insulting, then it's probably a genuine question! It's pretty sad when our hides get so thick that our immediate answer to a request for help is to try and ignore them.
To answer the original question, my guess is that it'll probably go into the latest unstable, which is Sid. (If it isn't in there already.) My guess is that it's probably not going to be around long enough to make the testing release, Sarge, before Sarge gets bumped to stable. From what I understand, to make Sarge, it'd need to be in for 3 months. If they bump Sarge to stable in less than 3 months, it won't make the next stable release. I could be wrong, here, though.
I don't personally run Debian anymore (Windows), so.. maybe someone from Debian could offer some insight here, on just how much work needs to be done to get this hooked in with the latest X, and what it would take for it to make it into Sarge.
Thanks for the tips! :) I did some research to check each of these out.
:) Last time I ran Linux, if I wanted to do anything 3D that changed the screen to fullscreen, I had to be root. I take it this has since changed.
I think that's what XRender does.
- How closely related are XRender and XAA? Is there a central repository of all of these extensions, and to what degree they've been accepted/supported by different tk's?
MS TrueType fonts and Xft.
- Why are we still depending on Microsoft for our font needs? How many fonts are there out there that aren't from Microsoft, or Corel or other proprietary companies, and still look decent enough to use in prefessional reports, etc.? How many decent free fonts are there available out for other languages, such as Japanese, Chinese, etc.? Is there a free font creation project anywhere? More importantly, is there even a free program out there for creating Truetype fonts?
X clipboard mechanism standard
- According to the article, the clipboard one allows for the cut/paste of ASCII data. What about image or audio data?
GNOME Clipboard Manager
- Why does this expose the different X-level parts of the clipboard to the user? All I should see in a clipboard manager is what I've copied in the past. Not COMPOUND_TEXT, ATOM_.. etc.
You run DRI apps as root?! *gasp*
Why can I run Tuxracer as normal user?
*grin* Withdrawn.
XEmbed. Work in progress.
Kickass!
BlueCurve and Keramik/Geramik provide a consistent look for both toolkits.
Ah. Is this a consistant look, though, or a consistant back end? What I'd like to see is a standardized back-end component that both link against for their theming capabilities, so that people can just target that one lib and have changes to themes for it change all of your desktop tk's.
The advantage I see, in these newer projects, is that they're willing to say "here, there are the objects you can use. If you want something new, build it out of these, but for basic stuff, this is what you use." It allows them to abstract out the simple stuff, so that stuff that should be run on the X server anyways can be.
An example of what I mean is a window manager set up to follow mouse focus. If I'm sitting at a box, and I move my cursor across the screen, each time I enter/exit a window, the focus changes. X kicks in, sends a message to the client, and the client updates the window to visually show that it's now got the focus. If I'm accessing a remote machine when I'm doing this, it can be slow as heck just to move the pointer across the screen.
The advantage of these newer kits is that stuff like this is all done on the server end. If it's just dumb interface stuff, the client doesn't even have to really worry about it. This results in reduced network traffic and reduced latency where it really matters; when the user is using the system.
Or is there a server-side window managing / toolkit access extension already out there for X that I don't know about? ^_^;
I'm sure if you think about it, you can come up with several other useful applications of something like this.
Things I think X needs, really quickly:
I wrote this yesterday. Please correct me (this post and that) where I'm wrong; I really do want to understand this stuff as best I can.
Hear, hear.
It's not that they don't look and feel the same. I personally think there's a more fundamental problem, and that problem is X.
:)
X was designed, from the start, to be a low-level API to allow different types of UNIX windowing systems to interoperate. It was designed to be quick on the hardware of that day, which was monochrome or paletted, and speedy across network connections like 300 baud. It was designed with the intention of people writing cheap toolkits for it, toolkits like Motif, that were low-bandwidth.
Now why did they go with the client-side toolkit idea? There are a few reasons. One is because the target machine wasn't always of the same architecture, and porting the library to another architecture could be a pain. Another is that it took more bandwidth to transfer the library to the user's side than it did to just send the basic drawing instructions.
Nowadays, we have two solutions to the first problem; we can either use a VM to run our libraries, or we can just compile it for them. (This is where Autoconf, Automake and libtool come in handy.) Worse comes to worst, we can have a fallback that uses an X remeniscient remote painting facility, if they don't have the tk installed.
The second problem is obsolete. Toolkits are now being themed, which means that we have huge numbers of image files being used to "paint" interfaces. If the machine that's the X server isn't the same as the X client, then these images are painted on the client and sent over the network to the server. Eek. Also, these are typically images that aren't natively supported by X (X only supports paletted images) so we need to use an extension, so programmers have some cruft to worry about, here, too. (ie; What if the extension's supported, but poorly, and it fails halfway through the call?)
Now don't tell me that we need to do things this way, because we don't. In the latest release of Windows, XP now has that level of network transparency. If you want to access your home computer's apps from work, it's as simple as logging into it from work. Instantly, your home drives appear in your explorer, and you can access windows on the screen of your home box.
Now why am I making such a big deal about this, you ask? Well, it's because they're not just taking a screenshot of the desktop and sending it. They've taken a page from X's book, and they send the higher-level commands over the network. Essentially, GDI calls. And, from what I understand, you end up with a consistant interface on the accessing end, because it uses the accessor's theme set.
Now this is just my rant about X's networking components. If you want to get into XFree86, I can tell you that I'm not at all pleased with the way they've set it up. X should not be the video driver. When I start my machine, I should not have to load X in order for my graphics card driver to be loaded. It should be loaded, waiting and ready to be accessed, by any application.
The way I see it, the system should come up by loading the graphics driver. It should be a process that's always running. Then there should be a standard library through which anyone can access the graphics driver. The card's state should be in the driver, not X! The driver should be in charge of the card, not X! X should be just another application that people can run to get a windowing environment.
The closest I can find to this idea, right now, is the libGGI/libGII/kgi people. They've got a basic framework for their API down, but it only works with a limited number of cards, and only one of those uses acceleration features so far. If that API were expanded for full 3D support, and a few more recent cards could be added to that list, or bumped up to full acceleration, I think we'd all be a lot better off. Heck, they've already got an Xggi server written--they've had it for years.
As for X on the desktop, GNOME had to hack a CORBA ORB to get the functionality that Windows provides for free. For X, the lack of standardization in the 3rd party object components department has been a huge pain in the ass for anyone interested in combining a KDE part with a GNOME widget in the same program. You end up having to port one of them the other way. If X could be made to have it's own object tracking extension, that would help bandaid the solution, but I think it's just a symptom of a much bigger problem.
X is old. It shows. We need something new; I say make X a plugin for whatever new windowing system we use tomorrow, and that we get started on making that new one soon.
If we want to put a GNU system on every desktop, X as the windowing system just isn't the right solution anymore.
And with that, I think I'm done.
I used Linux for a little over a year, three years ago. Several reasons forced me back to Windows, one of which was the need to have Visual Studio, but now that I'm a student again, there are still several things keeping me from going back:
.AVI files. It has no Premiere either, but let's not even go there..
.cdi and .nrg image file formats?
Virtual Dub - Linux has no equal for manipulation of
Cubase - Linux has no equal here either. (Installing five different packages of something so I can use something half written in Tcl/Tk and using Motif for a GUI doesn't count.) Likewise, show me how I can load my MIDI soundfonts for my Audigy under Linux automatically with every boot, without having to hack a boot script or cron job. (Or are soundfonts for MIDI even supported under Linux? Last time I checked they weren't..)
Hardware support - ATi Radeon 8500LE is not supported for 3D under Linux. Given as my main field of interest is 3D graphics, and I play with shaders all the time, there's no way in hell I'm going back without this.
Webcam - USB, and not supported under Linux. I'm not going to shell out for another one.
TV Tuner - Hauppauge, but just way too much work to set up under Linux. Would my remote control still work? If not, forget it.
Document support - Can you import PowerPoint files yet? One of my prof's notes are exclusively in those.
CDR burning - Does your burner app support
Games.
And now the biggie--X. I hate it. My reasons:
- It's not the OS, already, get over it. It shouldn't run as root, and it shouldn't be required for advanced graphics support. If someone wants to write a driver for a card, they shouldn't need to target DRI/DRM for best speed. If libGGI and KGI or something similar became the lowest level entry point for graphics, I'd be more than happy to switch back. But as long as X is calling the shots, I'm not interested.
- The interface is not centralized/standardized. Yes, I know why, but that's not why most people who'd use it on the desktop would use it today. (OSes whose interfaces I do like; BeOS, MacOSX.. Heck, even Windows is kinda nice. With Windows XP, you now have network transparency, and quicker than X, too. I think it's time to rethink this one.)
- I need Japanese entry support. Compared to the Microsoft IME, the X entry method is a turd, and a pain to toggle on/off, depending on the application. I'm either logged in in Japanese, or in English; there's no way to have Japanese entry with an English interface. Likewise, behaviour varies from toolkit to toolkit. Crap.
- GNOME is a dog. If you turn up it's settings so that visually, it's halfway acceptable, your speed drops to half, as things that modern video cards can compute easily are done on the CPU. Under Win2k, my Radeon 8500LE cheats, using it's 3D acceleration capabilities to help accelerate transparent objects, from dragged objects to windows to text.
- Windows has more useable fonts available out of the box, period. I don't care if X has more; if it looks like someone spat on the screen, I ain't usin' it.
No, it's because some of these planes are old, from way before cellphones quite as ubiquitous as they are now. They didn't have as strict of regulations concerning electrical signals back then, so some of the electronics in the older planes aren't shielded against the frequencies used by cellphones.
Rather than having different rules for different planes, and all of the confusion that comes from it, there's a blanket rule against cellphone usage. Makes things easier. For everyone.
I'm curious how one could program games to take advantage of the latter. Perhaps you know something about the OpenGL and Direct3D specs that I don't?
Direct3D currently does texture caching on it's own whenever you (as a programmer) choose to use "managed textures." If you try to run a (DirectX) game made for 64 megs on a 32 meg card, that hit you take is, more often than not, the textures swapping into "cache" every frame. Since any game programmer worth his salt has already optimized his engine to minimize texture set calls, you shouldn't often run into the situation where you're swapping the same texture in and out again. (Unless, of course, you need to render a lot of transparent textures, in which case you're screwed, since they all have to be rendered in Z-order. So even if some are the same, they can't be grouped. But I digress.)
In OpenGL, you can do caching too. You're just forced to do it all yourself. This can be helpful, because then you can tune the caching algorithm yourself... but then again, you can write your own caching system for Direct3D too, if you want, so it's not really a notch in OpenGL's favour not having this feature..
Here's a little tip; the big difference between ATi and nVidia cards for most games isn't the raw power of the card. No, it's the time spent making state changes. (That includes texture changes.) ATi cards are notoriously bad for running at one third of optimal if you don't optimize (and by optimize, I mean group 'em to minimize 'em) every single state call in your engine. nVidia just writes faster state change code; that's why their cards seem faster.
Not that this should really surprise most people. ATi's never been really renowned for their drivers. But it's just one of those things that can be really damaging. Especially when an engine programmer makes the assumption that hey, it doesn't matter if we set all these render states, the driver will optimize out those that aren't needed, and, lo and behold, ATi's don't..
Now mind you, I haven't played with a 9700. You never know; the times, they may be a changin'. But the 8500 drivers had this, and every card before it from them that I can remember.
Wow.. And I just bought the Monsters Inc. DVD, so now I feel all icky.. Bad Pixar, bad! :(
... Furthermore, placing the RM/RMC register on the stack is an impossibility without breaking backward compatibility; many assembly language coders depend on a set number of bytes being added to the stack when they perform a call or interrupt.
Why not just add 24 GP registers to the existing processor?
Aren't these two observations in conflict with eachother? Last time I checked, PUSHA/POPA still needed to be called in such situations. Unless you're talking about implementing yet another PUSHA/POPA extension instruction to go along with the new registers..
So yes, your solution would be possible, but you would need to add this instruction with it too, as a bare minimum.
The reason that he's proposing the remap, as opposed to just adding registers, is so he can keep on only using certain registers for certain tasks. Adding new registers means having to rewrite the old instructions so that they can use the new registers. Which means adding new opcodes to the list to support these different versions of the basic opcodes. Which I would see as being an absolutely insanely large modification to the instruction set.
Btw, both your and his proposals suffer from the problem of opcode re-ordering taking up a lot more of the silicon. Currently, the chip only has to know whether two sources and one destination are going to be defined whenever choosing where to put the instruction in the pipeline. (iirc) If you now have the ability to target other sources/destinations, suddenly all those optimizations you made when you put into silicon that these registers are always source, and this one's always destination, are thrown out the window. (And you want this use-for-any-opcode ability for all 24 of the new registers you propose as well?)
Now keeping these things in mind, what's the point in starting on something like this today, when they have another chip ready to come out in a few months? It just doesn't make any sense, from a business point of view.
One last thing; consider the amount of wasted space in x86 with just the current instructions alone. Every time they've added something new, the number of bytes for one operation's gone up. You want them to add more? Okay, assume it's feasible, and that people don't mind having 8-byte opcodes. What will AMD and Intel say to the prospect of emulating these opcodes in their next gen processors? Assume, for the moment, that the 64 bit processors aren't already taped out/near being taped out; how much of a pain in the ass would retooling the new processors to emulate either of these proposals be?
The real, and only solution, is that these companies get their acts together, quit issuing refreshes of old hardware, and finally give us their next gen chips to play with. Proposing anything else is just pointless. (Unless, of course, the new CPUs completely flop..)
Btw, ianae (I am not an engineer), just a lowly comp sci student, so take this all with a grain of salt. : )
I know! Linux is nowhere near that elegant.. ; )
(Just think of the security mechanisms on the X-Box as a challenging chastity belt. Ah, young love..)
Simple; Creative does it with Creative marketing.
The Audigy, for instance, is little more than a gamer's card. Any serious review of the card that you come across on the internet will tell you this, or if you bought it hoping for some advanced features, you'll find it out for yourself.
Here are some examples of this Creative marketing:
- The Audigy does support 24bit/96kHz sound playback, as advertised, but does not actually play it at that. The second it hits the main chip, it's downmixed to 16/44. So while you can play sound at the higher frequency to it, you're not actually going to hear it. (This is what they mean when they plaster 24/96 all over the boxart.)
- The Audigy does not have independant recording and playback volume controls on the line in. If you wish to record something on a TV tuner, for instance, then you'll have to either listen to it while it records, or turn off the global volume on your soundcard. (Or turn off the speakers.) This makes it impossible to use an Audigy in a PVR setup.
- The much-touted sub 100dB SNR is only on playback. On recording, the SNR is much higher.
I haven't been this disappointed in a card since my SB 128 upgrade ran slower than my SB 64. (I suspect the 64 did the soundfonts in hardware; the 128 did them in software.) Looking at the new Audigy 2, it appears that they'll be offering the 24/96 functionality that was insinuated to be present in the original Audigy, but I don't think I'll bite. I think my next card will be a Hoontech.
And, of course, this is all off-topic..
FYI: They don't wash the lettuce. It comes pre-washed and pre-cut in sealed plastic bags. All they do in the back is pull it out of the bag and spread it on the bun. Likewise all the other junk they put on the product. (It's the same at all of the fast food franchise spots.)
Since they'll have to update OpenSSL anyways, any chance people will move to the new Apache at the same time?
(I doubt it, because most network admins are rightly paranoid--may as well keep the devil you know than expose yourself to the devil you don't. Still.. wishful thinking..?)
There would be if he was growing with seed from a previous year, and it was the previous year's seed that had been contaminated.
What would really suck for this guy would be if his neighbour had been the one "stealing" for a few years beforehand, and if the g.m. stuff had gotten into his mixture back then. He'd have no way to show that the other guy's seed had been g.m.ed, and the other guy sure wouldn't have any incentive to tell anyone about it..
In short, the security for international flights in New Zealand was much better than in Hawaii.
Oh c'mon... who'd bomb Hawaii!?!
; )
That's like selling you a car saying it has 300HP, but in fact, only has 120.
No, it's more akin to saying it has 300HP, when they're really selling a 120HP engine that's been modified and tuned (but mostly tuned) to run at 280HP.
If you want encrypted IM for over a standard network, you can always give Miranda a shot. Setting up the GNU PG plugin with it can take a little bit of work, but it's possible.
I agree with you, though; something as simple as this should be included right out of the box with every chat client.
If you don't uninstall the old driver set before installing the new one, you can really mess up your system. Likewise if you had a NVidia card previously, and didn't completely uninstall the drivers for that before installing the Radeon ones. Did you upgrade without uninstalling at any time previously? If so, you may want to first unisntall your current drivers, and then pick through the registry for dangling settings from old cards. NVidia's site has a doc describing how to do this for their cards somewhere on their site..
Under Win2k+, ATi's drivers are rock-solid stable. Unless, of course, your motherboard has a lousy AGP driver, in which case you're screwed. (I've found that some motherboard manufacturers only cater to one brand of video card.)
It can be especially bad whenever you have a relatively new motherboard. Some manufacturers ship these things out, and the entire first revision of the board has a flaw. There was a whole generation of VIA chips like this a while back.. I think it was the KT133A chipset on a certain ASUS board.. I had one, but ended up returning it and getting the revision board.
The worst I've had, as far as instability's concerned, with my 8500LE, is a few occassional reboots whenever exiting an especially taxing 3D application. It is a bit annoying, but at least it doesn't lock hard like previous Windows versions did..
Incidentally, if it's your own code that's causing it to reboot/lock up, then I suggest you check your vertex shader setting code. I had a rebooting problem with my own code for a while, and it turned out to be that I was setting an invalid vertex shader. On a NVidia card, it'll just ignore it, and use the fixed function pipeline. On an 8500, the computer'll reboot. Likewise, if it's a specific game that's screwing up on just 8500s, then this could be the problem there as well.
Just my two cents..
Cheers..
Effects Browser requires that you write the plugin as you usually would, compile, and create a .dll for it, etc., and then you can view it in the Effects Browser. (From the Effects Browser you can't change anything; only view.)
With RenderMonkey, you don't worry about C/C++ at all. All of the settings (constants, input textures, etc.) for the shader are nicely displayed on the left, and you can just click and change them as you wish. This is absolutely nothing like NVidia's Effects Browser.
Maybe the 9700, but the 8500's a whole different monkey. In order to squeeze the extra performance out of the pixel shader, they have a phase instruction which allows the shader to make a second pass, and do dependant texture reads. Something like that'd be hard to compile code to use, I'd wager. At the very least, it'd require the developer know how to tweak Cg code to get it to compile nicely for the 8500, which would probably require they know the assembly-level stuff anyways.
Remember that the 9000 is essentially a modified 8500. They aren't totally getting rid of this architecture yet; they want people to still support it as much as possible. Hence the desire to stick to assembly-level shader coding as long as possible.
Overall, RenderMonkey looks like a nice, useful shader-creation environment for prototyping assembly-level shaders in. All they need to do is add support for OpenGL2's shader language, and Microsoft's, when they come out, and I'm sold.
(And before anyone pipes up that that's Cg, Cg's a totally different product; it's a language, compiler, libraries, etc, but mostly a language spec. RenderMonkey's aiming to be a complete content management system. Cg's for programmers who write tools, RenderMonkey's a tool for your programmers and artists.)
The Radeon 8500's video drivers do transparency in hardware, if I remember correctly..
I like the intro. Mind you, I don't watch the show every week, preferring to catch it in reruns, so I don't get a continued and repeated dosage of it. Plus I happen to like country, and I grew up on easy listening, so my tastes are probably vastly different from everyone else's.
This intro's still a million times better than Voyager's, though. That intro theme could put a person to sleep. Actually, come to think of it, it has..
As for the blueprints thing, I wouldn't give them much credit. I'll bet you anything the only reason they're there is (a) because it looks cool, and (b) because Archer's father supposedly designed the ship, and they want to milk that for all it's worth. But mostly I think it's because of (a).
And now for something completely different.
I would like to propose the following; Video Mute. Instead of muting the audio, it would turn the video image contrast down, averaging out the video as much as possible without completely eliminating the video. This would be extremely helpful for whenever I'm watching television and an especially stupid commercial comes on that strobes. every. second. binding. you. (And hey, it might even make music videos watchable.)
Mute + Video Mute would be perfect for those of us who (a) can't afford a Tivo, and (b) want to avoid being distracted by the stupid flashing while we're trying to talk with fellow viewers, or read a book during commercials.
I hereby promise not to patent this idea, and I hereby give everyone in the universe free and unrestricted right to implement and use it, blah blah blah.. or has someone already thought this up and patented it? : )