I don't think your solution is proper either, although your solution prevents the buffer overflow, it can still cause the app to crash. If the string isn't null terminated, strlen() could cause a segfault (someone correct me if I'm wrong).
A better solution is to do what was stated in the presentation, use strncpy(), then add your own '\0' to the end (its more efficient too, since you don't spend time in strlen).
People already own the hardware(!), they've invested lots of money in their computers. Their not going to pay for an extra computer just to play with OS X! Its like if you had to buy a specific brand of car just so you can install a kick ass car stereo on it. It doesn't matter how good the stereo is, if its not going to fit on my already purchased car, I'm not going to buy it. Same goes for computers & OSes.
For a simple enough high speed link, you can do I/O bist using external loopback. Or alternatively, use a second know good device on the loadboard to test it. Of course it should be used only for detecting manufacturing defects, you need to do a lot of testing up front to convince yourself that the part will actually meet specs across process variations.
For those who don't know, IC testers are big ass machines used to production test chips (i.e. screen out the good chips/dice from the bad ones).
Intel uses testers from
schlumberger (their reps are quick to point that out). Typically, a tester cost anywhere from 1-10 million dollars + plus they require a lot of maintenance, calibration, etc. Basically, the faster and more pins you need, the more it cost.
I've worked with some schlumbeger 'KX' testers, they're a big pain in the ass, unreliable, and are badly designed: just shutting the thing off can break it!! (especially if you use the emergency off button).
There is another choice, however, you can use 'bist'(built-in self test) and have the chip basically test itself:-). This allows companies to get away with using cheaper, more reliable testers.
Yeah, I was thinking the same thing when I read the article, they make it sound like Fibing is some kind of amazing "proprietary" intel invention or something.
"Watchout AMD, Intel can FIB!...they also have a few soldring irons too":-)
Furthermore, one really nice feature that it has that the OSS modules don't is the ability to play multiple sound streams at once via software mixing. That alone is enough to make me want to use it.
This is false, the OSS-compatible driver has been able to handle multi-opens since Nov 1999, the same month they were opensourced (
main.c rev 1.22). Alsa got emu10k1 support in ~january 2000. Furthermore, sound stream mixing is done by the emu10k1, not software.
That's were flipchip has an advantage, you can more freely place your bumps (the flipchip equiv of a pad) anywhere on die. The I/O cicuitry still take up a lot of space(output buffers/esd protections), but at least you aren't stuck with empty space in the middle. Another pro is no bondwire inductance, which is good for high data rate I/Os. Main downside is the high cost of the substrate (i.e. package), this can be a big problem for high volume/low-margin chips like CPU.
Anyway, with 3MB of onboard cache, I doubt the I/O pads are to blame for the large die size of this CPU.
The folks who made GTA3 went to the trouble of setting up websites for the companies mentioned in the games, like http://petsovernight.com/
for example.
I'm on an 1400x1050 LCD (24bit), and I agree with the above poster, the OSX image looks very blurry. Were both of these screen shots intended for LCD screens?
As a side note, if a port in parallel isn't realistic, then my argument that loki had a bad business model still stands. Releasing well after the windows version is simple dumb.
(It might make more sense for mac users, though, since they can't reboot into windows.)
In the move industry, for example, translations are done while the movie is still being produced (music, editing, etc). Movies released in French in Quebec, for example, get release the very same day as the english movies in the rest of north america. There's no extra delay to the release schedule do to the translation effort.
Doing a port is a little like doing a translation, most of the core work is the same (graphics, music, etc.), and so most of the porting work can be done while development on these is on going.
I think the major problem with this (or at least loki's) business model is the fact they ported games after the windows games were already out. You need to cordinate and release at the same time.
People aren't going to sit around and wait 6-12 month for a port when they can just reboot into windows a play the already released game. How can you possibly expect people to buy a second copy 6-12months later just to play it under linux?
Depends, for system wide configs, having/etc/ entries makes backups for individual services/programs much easier, though I guess most people don't need that, in which case a registry is ok.
Using a registry for user setting, though, is a PITA, IMHO. Nothing beats the unix method of '.' files/directories in the users home directory interms of KISS-ness. You can very easy backup your settings, copy them to a different machine, or try out a friends settings, etc, all on a per program basis. A registry (esp Windows registry), makes it very difficult to do such a thing.
For example, I've been using the same.emacs file now for 5+ years now on a ton of different machines (solaris, linux, HP-Ux - at school, home and work). In the same time, I've had to reconfigure Office to my liking a countless number of times.
I've never had so much moderation done to one of my post:
Moderation Totals: Flamebait=1, Insightful=2, Interesting=1, Informative=1, Funny=3, Overrated=2, Underrated=1, Total=11.
I think I'm only missing 'troll' and 'offtopic' and It would have been a full house.
You expect the kernel developers to follows every windows bug and try to figure out if its infact a software or hardware bug? Fact is, AMD made this look like a windows bug,
read it for yourself(its over to the top right).
To me, this looks like AMD doesn't give a rats ass about its customers customers who use linux.
RTFA, AMD released a patch for w2k but never mentioned anything to the kernel developers.
Instead of saying "oops, there a hardware bug", they said, "oops, here' a patch for w2k". Looks like none of the kernel developers knew they had to look a w2k bug fixes to find out about hardware bugs.
I am willing to bet that the need for transparent networking, while really freaking cool and useful, has deminished greatly in recent years, especially with desktops becoming much more powerful and with the move away from terminal/host to client/server computing.
This is true for home users and non-technical workers (secretaries, etc), but for Engineering/Scientific corporate and education settings, X network transparency is an amazingly useful feature. Not a day goes by that I don't use a remote X app at work.
For one, some engineering and scientific software only comes for one arch (solaris or HP).
In a mixed environment (solaris, hp, linux, and even Windows worksations), you can run these apps from your workstation regardless of which OS the remote computer is running (even windows, with cytrix).
Secondly, these apps usually cost a lot of money and are a pain to maintain. Installing on only a handfull of servers probably makes our admin's job a lot easier (which means less problems for us users).
The only feature I wish it had was the ability to move an app from one Xserver to another while it running, or the ability to disconnect from an X server and have the app connect to a gui equivalent of/dev/null. Both of these are available with VNC, but I wish the X protocol had support for this naitively.
That's not the problem. As I recall, with 'show window contents when dragging' disabled, when you move a window it shows a boxed outline, it only moves the window once you've place the box.
What I'm talking about here is what happens to the other windows in the background while moving a window. They don't refresh themselves. Could be a driver issue I guess.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
One of your points address non-xfree related thing:
Design the GUI interfaces without a mouse. Everything should be accessible through a keyboard, no exceptions.
This is totally a toolkit issue. gtk/gnome2 has addressed this issue and everything will be easily accessible via keybaord. I'm not sure where qt/kde stand on this.
I don't see this problem at all. I can move windows and have have others update underneath. Maybe its a driver specific issue?
Infact, what you described is exactly one of my big gripes I have with MS Window (NT4, to be specific). You just click on a window to move it (not even actually move it) and all other apps freeze. Quite anoying.
Re:Moving away from X
on
Xfree86 4.2.0 Out
·
· Score: 4, Informative
most Linux distros by default *don't* have good fonts
Slashdot Mirror
Granted: February 5, 2002
A better solution is to do what was stated in the presentation, use strncpy(), then add your own '\0' to the end (its more efficient too, since you don't spend time in strlen).
People already own the hardware(!), they've invested lots of money in their computers. Their not going to pay for an extra computer just to play with OS X! Its like if you had to buy a specific brand of car just so you can install a kick ass car stereo on it. It doesn't matter how good the stereo is, if its not going to fit on my already purchased car, I'm not going to buy it. Same goes for computers & OSes.
For a simple enough high speed link, you can do I/O bist using external loopback. Or alternatively, use a second know good device on the loadboard to test it. Of course it should be used only for detecting manufacturing defects, you need to do a lot of testing up front to convince yourself that the part will actually meet specs across process variations.
Intel uses testers from schlumberger (their reps are quick to point that out). Typically, a tester cost anywhere from 1-10 million dollars + plus they require a lot of maintenance, calibration, etc. Basically, the faster and more pins you need, the more it cost.
I've worked with some schlumbeger 'KX' testers, they're a big pain in the ass, unreliable, and are badly designed: just shutting the thing off can break it!! (especially if you use the emergency off button).
There is another choice, however, you can use 'bist'(built-in self test) and have the chip basically test itself :-). This allows companies to get away with using cheaper, more reliable testers.
"Watchout AMD, Intel can FIB! ...they also have a few soldring irons too" :-)
This is false, the OSS-compatible driver has been able to handle multi-opens since Nov 1999, the same month they were opensourced ( main.c rev 1.22). Alsa got emu10k1 support in ~january 2000. Furthermore, sound stream mixing is done by the emu10k1, not software.
It must be the political spelling: Governor pushs math initiative
Anyway, with 3MB of onboard cache, I doubt the I/O pads are to blame for the large die size of this CPU.
I'm on an 1400x1050 LCD (24bit), and I agree with the above poster, the OSX image looks very blurry. Were both of these screen shots intended for LCD screens?
As a side note, if a port in parallel isn't realistic, then my argument that loki had a bad business model still stands. Releasing well after the windows version is simple dumb. (It might make more sense for mac users, though, since they can't reboot into windows.)
In the move industry, for example, translations are done while the movie is still being produced (music, editing, etc). Movies released in French in Quebec, for example, get release the very same day as the english movies in the rest of north america. There's no extra delay to the release schedule do to the translation effort.
Doing a port is a little like doing a translation, most of the core work is the same (graphics, music, etc.), and so most of the porting work can be done while development on these is on going.
People aren't going to sit around and wait 6-12 month for a port when they can just reboot into windows a play the already released game. How can you possibly expect people to buy a second copy 6-12months later just to play it under linux?
Using a registry for user setting, though, is a PITA, IMHO. Nothing beats the unix method of '.' files/directories in the users home directory interms of KISS-ness. You can very easy backup your settings, copy them to a different machine, or try out a friends settings, etc, all on a per program basis. A registry (esp Windows registry), makes it very difficult to do such a thing.
For example, I've been using the same .emacs file now for 5+ years now on a ton of different machines (solaris, linux, HP-Ux - at school, home and work). In the same time, I've had to reconfigure Office to my liking a countless number of times.
Moderation Totals: Flamebait=1, Insightful=2, Interesting=1, Informative=1, Funny=3, Overrated=2, Underrated=1, Total=11.
I think I'm only missing 'troll' and 'offtopic' and It would have been a full house.
To me, this looks like AMD doesn't give a rats ass about its customers customers who use linux.
Rather, AMD fixed it for microsoft, they made the w2k patch but didn't release a linux patch.
Instead of saying "oops, there a hardware bug", they said, "oops, here' a patch for w2k". Looks like none of the kernel developers knew they had to look a w2k bug fixes to find out about hardware bugs.
This is true for home users and non-technical workers (secretaries, etc), but for Engineering/Scientific corporate and education settings, X network transparency is an amazingly useful feature. Not a day goes by that I don't use a remote X app at work.
For one, some engineering and scientific software only comes for one arch (solaris or HP). In a mixed environment (solaris, hp, linux, and even Windows worksations), you can run these apps from your workstation regardless of which OS the remote computer is running (even windows, with cytrix).
Secondly, these apps usually cost a lot of money and are a pain to maintain. Installing on only a handfull of servers probably makes our admin's job a lot easier (which means less problems for us users).
The only feature I wish it had was the ability to move an app from one Xserver to another while it running, or the ability to disconnect from an X server and have the app connect to a gui equivalent of /dev/null. Both of these are available with VNC, but I wish the X protocol had support for this naitively.
What I'm talking about here is what happens to the other windows in the background while moving a window. They don't refresh themselves. Could be a driver issue I guess.
Design the GUI interfaces without a mouse. Everything should be accessible through a keyboard, no exceptions.
This is totally a toolkit issue. gtk/gnome2 has addressed this issue and everything will be easily accessible via keybaord. I'm not sure where qt/kde stand on this.
Yes, I see, it continues to scroll perfectly fine. Perhaps check you xconfig, you must have something not set properly.
Infact, what you described is exactly one of my big gripes I have with MS Window (NT4, to be specific). You just click on a window to move it (not even actually move it) and all other apps freeze. Quite anoying.
Its really easy to fix: webfonts-1-3.noarch.rpm
Make sure to read the MS Eula included.