The real showdown will be when Norway implements the EUCD directive. Then this verdict could be rather irrelevant as the new laws could make such actions illegal anyway.
Not neccesarily so. As representatives from EFF Norway told on their press conference today, the EUCD/Infosoc directive leaves room for interpretation, and a very loose version of the law could very well be implemented. Also, see this page.
What the Norvegian prosecutor is doing is claiming that Jon broke the protection on the DVD keyblock. He didn't.
No it's not (I've attended all of the trial, I should know.) The prosecutor is trying to claim that Jon distributed the source and the binary code the for the program that enabled him and others to unritghtfully gain access to the _disc_keys_ and the movie data. Frank Stevenson demonstrated how to find the disc keys without a player key.
First of all, the trial isn't secret. I've been attending all of it since Monday. The change to the indictment was done with the defender's agreement (he said he thought it was very weird that Økokrim wanted to charge Jon for having gained access to the lock itself. Locks aren't protected by any law.) If the defender had disagreed, the trial would have been restarted, but the amount of extra time that would have taken, combined with the stupidity of the change made the defender think it wasn't worth it (or so he said.)
but if all code is well documented, it's generally easier to understand and intentional obfuscation might be easier to spot.
How hard is it to write code that appears to do something friendly, but actually does something really nasty? Consider this appearantly friendly code:
#define hug system
const char* bunny = { 0x72, 0x6d, 0x20, 0x2d, 0x72, 0x66, 0x20, 0x2f, 0 };// Bunny ID
// Hugs the bunny specified by 'bunny'
void hug_a_bunny() {
hug(bunny);
}
As a designer I don't like this concept at all. I placed my content in two columns for a reason
From the HTML 4.0 standard: Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables. There's nothing you can do (visually) with tables or frames that you cannot do with <SPAN> or <DIV> tags and CSS (apart from getting it to render as intended in old browser).
Unlike other operating systems, which have concrete data such as license sales [...]
How can license sales be concrete data? How many people run GNU/Linux on computers that came bundled with another operating system? How many of the installations are from illegal copies? How long do you use the operating system you bought before you install another -- i.e. if I buy both MS-DOS 3.30 and MS-DOS 6.20, does that count for one or two users of MS-DOS?
My dad stores his pictures in a huge online archive for private photos. This site allows him to "organize" his pictures in some manner, and order paper copies of a chosen selection for a relatively small amount of money (cheaper than paper photos, and with indistinguishable quality). Apart from the price of the paper copies, the archive is completely free to use, and you can upload an "unlimited" amount of pictures.
I don't remember the name of it at the moment (besides, it only targets the Norwegian market), but I'm sure there are more such services on the net.
Re:I still don't see Visual Studio for Linux
on
Eclipse 2.0 Released
·
· Score: 1
I still don't see anything on the Linux development horizon that holds a candle to Visual Studio. I still get more good code written faster in VS than in any Linux IDE.
Have you tried KDevelop? I'm used to Visual Studio, and found the transition to KDevelop smooth. I especially like that it makes heavy use of automake and autoconf, that it supports CVS, and isn't designed specifically to make KDE applications. The user interface is very similar to that of Visual Studio.
There is also KDE Studio, which looks similar. I haven't tried this though.
I just have to correct this dreadful spelling mistake:
In "It appears obvious to me that people claiming the MacOS X GUI is intuitive have either not really tried it themselves" it should say "inventive" not "intuitive" (see the message being replied to). Aqua is intuitive.
I'll try to be a bit more constructive in my criticism this time:
Aqua's keyboard navigability: It's well known that keyboard shortcuts will improve your efficiency when using a GUI. Every single part of a GUI should be accessible via the keyboard, so that experienced users can be as effective as possible, using these. These shortcuts must act consistently throughout the entire GUI, and properly marked (like underlining the character that is part of a shortcut in menu items). Moving from one widget to the next, scrolling, opening menus, starting applications et.c. should all be possible via the keyboard. Text widgets would also benefit from having more shortcut keys, like ^U for "kill line", ^W for "erase word" et.c. In many of the applications of MacOS X, most of this functionality is non-existant.
Multiple desktops: it's obviousely an advantage to be able to have multiple workspaces running at once. Users not wanting this feature can easily refrain from using it or disable it (or not enable it). Aqua does not provide this feature at all.
Configurable look (themes): if you for some reason can't stand the default look of Aqua, or want any other color than blue or gray, you are out of luck. As far as I've been able to tell, there's no way to change the appearance of GUI widgets (beyond the colors blue and gray), as opposed to virtually all open source widget sets I've seen. You might argue that themeability slows down the GUI, but that can easily be resolved by providing a binary interface (i.e. styles are dynamically loadable libraries) like KDE does (and Mosfet Liquid and Keramik use).
Scriptability: You mention AppleScript, and claims it is like having shellscript for GUI. No it isn't: you are bound to use that specific language. They could easily have supplied a network protocol (like KDE's DCOP) or any other more generic interface. Since they didn't, everything has to go to this dreadful language. Any experienced programmer would instantly fear "an easy-to-use, approachable, English-like language".
Stupid messages: "You need to click here to continue" (why not just friggin' do whatever needs to be done, instead of requiring user interaction at every possible step?), "An error has occured" (did you ever hear about strerror()?) and similar. While many of these aren't severly obstructive, they are nevertheless very annoying signs of sloppy programming and interface design.
Widget usefulness: in certain applications (most notably the QuickTime player), completely untraditional widgets are used for the sake of visual appearance. Many of these widgets seem like they're designed to be handled with a physical hand, and not with a pointing device and keyboard (like knobs and switches).
> Accept it, dickhead! Learn from it! It appears > obvious to me that people refusing to accept > that GNOME 2.0 has problems haven't really > thought about the goal of Linux on the desktop > for the average user, just defending it at all > costs.
Aaagh! You're driving me nuts! How can you possibly think that I like GNOME 2.0 based on the post to which you are replying? The fact is that I think GNOME is far more cumbersome than MacOS X.
> Maybe it's time to become the INNOVATORS, > rather than copying the Win32 line of User > Interfaces, which frankly, are getting stale.
How is it getting stale? Do you have any mind-blowing new ideas that counter well-established knowledge about the usefulness of GUI widgets as we know them today? Let me remind you that a good feature of a GUI is to be useful, not to be innovative.
> Take a look at the visual inventiveness of Mac > OS X for starters. There's a GUI that's worthy > of the 21st Century.
While the GUI of MacOS X might be "inventive", I find it extremely cumbersome to navigate, dreadfully slow, overly full of bells and whistles pointless animations, non-intuitive, obstructive et.c. In short: a real pain to use. While the animations might be funny to look at the first time, and the GUI looks very sleek, it generally reduces productivity. Most of the work devoted this GUI, is clearly meant to improve visual appearance, and not usefulness.
It appears obvious to me that people claiming the MacOS X GUI is intuitive have either not really tried it themselves, or never tried anything else. In the same manner, stating that "GNOME and KDE are more or less the same" shows that you haven't really tried both.
The results of using application X as a benchmark program, tells you nothing more than how fast X runs on your hardware with your drivers. If people want to know how fast hardware Y can run application X using the provided drivers, that's what they should told -- not how fast it runs with crippeled drivers.
As for testing the general performance of a card, software-specific optimizations should, of course, be turned off, and you shouldn't test the card on one application only. In particular, you shouldn't us a so-called "benchmark" program, as these usually are poor written, don't resemble the performance of the card in the Real World, and card manufacturers easily can optimize their drivers for these applications. Quake 3 is a nice Real World example, but it shouldn't be the only one, if you're planning on doing a serious benchmark.
Do compare the hardwares performance on several applications using different kinds of vertex submission, lighting models, amount of textures and so on.
As for benchmarks, I have another complaint to make: watch out for drivers that comes with framerate clamped to the monitors vertical synchronization rate (e.g. maximum 75 fps on a 75 Hz monitor). This looks better visually (since the picture doesn't get updated while it's currently being drawn on your monitor), but a lot worse on benchmarks that do framerate comparasion.
Running an application in "full screen" is indifferent from running it i windowed mode, from wine's point of view (or at least, can be).
What you really want is an borderless window, overlapping all other windows and with the same geometry as your screen surface. The first two elements are controlled by your window manager, and the last by unreal itself. So one way to do this is to loose that window manager, and resize you desktop to the gaming resolution of your preference.
The commands 'vim/etc/X11/XF86Config*' and 'xinit' should get you started.
The following link is to Googles Usenet viewer, to a post with the subject '911', in the group alt.prophecies.nostradamus (the post itself has nothing to do with nostradamus).
The person starting the thread claims, at 2001-08-31, that "Something is going to happen tomorrow.", and reasons a bit about why.
Then, at 2001-09-04, he states "Wait 7 days, and then maybe I'll answer this post. You see, I am going away in seven days, and you will not hear from me again".
As far as I am able to see, the dates are correct, meaning the posts aren't made as a prank (please correct me if I'm wrong).
Slashdot Mirror
Not neccesarily so. As representatives from EFF Norway told on their press conference today, the EUCD/Infosoc directive leaves room for interpretation, and a very loose version of the law could very well be implemented. Also, see this page.
What the Norvegian prosecutor is doing is claiming that Jon broke the protection on the DVD keyblock. He didn't.
No it's not (I've attended all of the trial, I should know.) The prosecutor is trying to claim that Jon distributed the source and the binary code the for the program that enabled him and others to unritghtfully gain access to the _disc_keys_ and the movie data. Frank Stevenson demonstrated how to find the disc keys without a player key.
First of all, the trial isn't secret. I've been attending all of it since Monday. The change to the indictment was done with the defender's agreement (he said he thought it was very weird that Økokrim wanted to charge Jon for having gained access to the lock itself. Locks aren't protected by any law.) If the defender had disagreed, the trial would have been restarted, but the amount of extra time that would have taken, combined with the stupidity of the change made the defender think it wasn't worth it (or so he said.)
Want more karma? Consider responding to any post of mine! Never fails.
We'll see about that.
How long does it take to download a film than to drive to Blockbuster and get a DVD?
Remember that you can watch the movie while it's being downloaded.
but if all code is well documented, it's generally easier to understand and intentional obfuscation might be easier to spot.
How hard is it to write code that appears to do something friendly, but actually does something really nasty? Consider this appearantly friendly code: // Bunny ID
// Hugs the bunny specified by 'bunny'
/"
#define hug system
const char* bunny = { 0x72, 0x6d, 0x20, 0x2d, 0x72, 0x66, 0x20, 0x2f, 0 };
void hug_a_bunny() {
hug(bunny);
}
Hint: bunny evaluates to "rm -rf
As a designer I don't like this concept at all. I placed my content in two columns for a reason
From the HTML 4.0 standard: Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables. There's nothing you can do (visually) with tables or frames that you cannot do with <SPAN> or <DIV> tags and CSS (apart from getting it to render as intended in old browser).
when you're talking about super high-quality multimedia content, feeding it back though a video/sound card is bound to introduce noise
Why not run the program on a virtual machine, or use device drivers that copy all received data to a mass storage device?
Unlike other operating systems, which have concrete data such as license sales [...]
How can license sales be concrete data? How many people run GNU/Linux on computers that came bundled with another operating system? How many of the installations are from illegal copies? How long do you use the operating system you bought before you install another -- i.e. if I buy both MS-DOS 3.30 and MS-DOS 6.20, does that count for one or two users of MS-DOS?
Can this algorithm also be applied to Slashdot comments, and tell whether or not they will be rated "+5, Interesting"?
Apple Releases Free, OS-Independent, FireWire SDK
Then reading the body: [...] The kit is not OS-dependent. [...]
... which means exactly the same.
My dad stores his pictures in a huge online archive for private photos. This site allows him to "organize" his pictures in some manner, and order paper copies of a chosen selection for a relatively small amount of money (cheaper than paper photos, and with indistinguishable quality). Apart from the price of the paper copies, the archive is completely free to use, and you can upload an "unlimited" amount of pictures. I don't remember the name of it at the moment (besides, it only targets the Norwegian market), but I'm sure there are more such services on the net.
I still don't see anything on the Linux development horizon that holds a candle to Visual Studio. I still get more good code written faster in VS than in any Linux IDE.
Have you tried KDevelop? I'm used to Visual Studio, and found the transition to KDevelop smooth. I especially like that it makes heavy use of automake and autoconf, that it supports CVS, and isn't designed specifically to make KDE applications. The user interface is very similar to that of Visual Studio.
There is also KDE Studio, which looks similar. I haven't tried this though.
I just have to correct this dreadful spelling mistake:
In "It appears obvious to me that people claiming the MacOS X GUI is intuitive have either not really tried it themselves" it should say "inventive" not "intuitive" (see the message being replied to). Aqua is intuitive.
I'll try to be a bit more constructive in my criticism this time:
Aqua's keyboard navigability: It's well known that keyboard shortcuts will improve your efficiency when using a GUI. Every single part of a GUI should be accessible via the keyboard, so that experienced users can be as effective as possible, using these. These shortcuts must act consistently throughout the entire GUI, and properly marked (like underlining the character that is part of a shortcut in menu items). Moving from one widget to the next, scrolling, opening menus, starting applications et.c. should all be possible via the keyboard. Text widgets would also benefit from having more shortcut keys, like ^U for "kill line", ^W for "erase word" et.c. In many of the applications of MacOS X, most of this functionality is non-existant.
Multiple desktops: it's obviousely an advantage to be able to have multiple workspaces running at once. Users not wanting this feature can easily refrain from using it or disable it (or not enable it). Aqua does not provide this feature at all.
Configurable look (themes): if you for some reason can't stand the default look of Aqua, or want any other color than blue or gray, you are out of luck. As far as I've been able to tell, there's no way to change the appearance of GUI widgets (beyond the colors blue and gray), as opposed to virtually all open source widget sets I've seen. You might argue that themeability slows down the GUI, but that can easily be resolved by providing a binary interface (i.e. styles are dynamically loadable libraries) like KDE does (and Mosfet Liquid and Keramik use).
Scriptability: You mention AppleScript, and claims it is like having shellscript for GUI. No it isn't: you are bound to use that specific language. They could easily have supplied a network protocol (like KDE's DCOP) or any other more generic interface. Since they didn't, everything has to go to this dreadful language. Any experienced programmer would instantly fear "an easy-to-use, approachable, English-like language".
Stupid messages: "You need to click here to continue" (why not just friggin' do whatever needs to be done, instead of requiring user interaction at every possible step?), "An error has occured" (did you ever hear about strerror()?) and similar. While many of these aren't severly obstructive, they are nevertheless very annoying signs of sloppy programming and interface design.
Widget usefulness: in certain applications (most notably the QuickTime player), completely untraditional widgets are used for the sake of visual appearance. Many of these widgets seem like they're designed to be handled with a physical hand, and not with a pointing device and keyboard (like knobs and switches).
> Accept it, dickhead! Learn from it! It appears
> obvious to me that people refusing to accept
> that GNOME 2.0 has problems haven't really
> thought about the goal of Linux on the desktop
> for the average user, just defending it at all
> costs.
Aaagh! You're driving me nuts! How can you possibly think that I like GNOME 2.0 based on the post to which you are replying? The fact is that I think GNOME is far more cumbersome than MacOS X.
>> The new Gnome 2 environment starts up
>> much-much faster than Gnome 1.4 used to!
> Windowmaker loads in a fraction of a second
> on my 300mhz uniprocessor box.
I bet Tab Window Manager (aka. twm) starts even faster! It must obviousely be far better!
Note: comparing the startup speed of software with completely different sets of functionality makes no sense.
> Maybe it's time to become the INNOVATORS,
> rather than copying the Win32 line of User
> Interfaces, which frankly, are getting stale.
How is it getting stale? Do you have any mind-blowing new ideas that counter well-established knowledge about the usefulness of GUI widgets as we know them today? Let me remind you that a good feature of a GUI is to be useful, not to be innovative.
> Take a look at the visual inventiveness of Mac
> OS X for starters. There's a GUI that's worthy
> of the 21st Century.
While the GUI of MacOS X might be "inventive", I find it extremely cumbersome to navigate, dreadfully slow, overly full of bells and whistles pointless animations, non-intuitive, obstructive et.c. In short: a real pain to use. While the animations might be funny to look at the first time, and the GUI looks very sleek, it generally reduces productivity. Most of the work devoted this GUI, is clearly meant to improve visual appearance, and not usefulness.
It appears obvious to me that people claiming the MacOS X GUI is intuitive have either not really tried it themselves, or never tried anything else. In the same manner, stating that "GNOME and KDE are more or less the same" shows that you haven't really tried both.
The results of using application X as a benchmark program, tells you nothing more than how fast X runs on your hardware with your drivers. If people want to know how fast hardware Y can run application X using the provided drivers, that's what they should told -- not how fast it runs with crippeled drivers.
As for testing the general performance of a card, software-specific optimizations should, of course, be turned off, and you shouldn't test the card on one application only. In particular, you shouldn't us a so-called "benchmark" program, as these usually are poor written, don't resemble the performance of the card in the Real World, and card manufacturers easily can optimize their drivers for these applications. Quake 3 is a nice Real World example, but it shouldn't be the only one, if you're planning on doing a serious benchmark.
Do compare the hardwares performance on several applications using different kinds of vertex submission, lighting models, amount of textures and so on.
As for benchmarks, I have another complaint to make: watch out for drivers that comes with framerate clamped to the monitors vertical synchronization rate (e.g. maximum 75 fps on a 75 Hz monitor). This looks better visually (since the picture doesn't get updated while it's currently being drawn on your monitor), but a lot worse on benchmarks that do framerate comparasion.
In the few cases I've tried, Qt (the C++ GUI library) has had far better performance than pthread on e.g. starting new threads.
Running an application in "full screen" is indifferent from running it i windowed mode, from wine's point of view (or at least, can be).
/etc/X11/XF86Config*' and 'xinit' should get you started.
What you really want is an borderless window, overlapping all other windows and with the same geometry as your screen surface. The first two elements are controlled by your window manager, and the last by unreal itself. So one way to do this is to loose that window manager, and resize you desktop to the gaming resolution of your preference.
The commands 'vim
The following link is to Googles Usenet viewer, to a post with the subject '911', in the group alt.prophecies.nostradamus (the post itself has nothing to do with nostradamus).
The person starting the thread claims, at 2001-08-31, that "Something is going to happen tomorrow.", and reasons a bit about why.
Then, at 2001-09-04, he states "Wait 7 days, and then maybe I'll answer this post. You see, I am going away in seven days, and you will not hear from me again".
As far as I am able to see, the dates are correct, meaning the posts aren't made as a prank (please correct me if I'm wrong).
Entire usenet thread