Later, by fall of this year, the new boxed "2006" release will fully integrate Conectiva technology and Mandrakesoft online services into a new product. It will be released through traditional retail channels as well as by direct sale from Mandrakestore and Mandrakeclub, and will offer all support options and related services.
Note that there is no mention of a download option for Mandrakeclub. Am I missing something?
Mod parent up.
Posted here, can't moderate. Seriously, the AC is right. FireFox has a reasonable implementation of tabs, the extensions are there and are OK (though I just cannot understand why tab drag&drop is not in the base install), but to say that they are the best implementation of tabs and that nothing more should be done in that area is a *HUGE* stretch.
Just to notice, this is not the original report on the issue. The first publication was a CACM article "The Homograph Attack", which featured a spoofed version of www.microsoft.com. See details here:http://www.cs.technion.ac.il/~gabr/papers/hom ograph.html.
Funny thing: at first, I included only the "here" as the text of the <a> tag. But then I thought: why should you trust to click a link if it can be homographed...
I have always had the problem on R40, where it suspends OK, but refuses to wake up 'cause it doesn't recognize the LID button. There was a kernel patch that should take care of that, but I never succeeded to get through it.
Did you experience this problem? And, is it gone in 2.6.11?
1. Rotational speed doesn't matter - video recording is a matter of sequential writing, and the density of this thing would more than compensate for RPM. Moreover, it's not that far-fetched to assume MPEG-2 encoding on such a device.
2. 80GB ought to be enough for quite a couple of hours o'video. Now correct me if I'm wrong, but I see no use of more than 10 hours off of any single event... and moreover, you wouldn't have enough storage to keep them on your comp anyway.
3. The whole point is that you will ultimately edit all the video on your computer. Said that, the only editing feature you need from the recorder is the *DELETE* button. All the rest shouldn't be done on the device itself.
DISCLAIMER: said all that, I'm currently not an owner of any video cam, and my opinion could change when I do get one.
Ok, you misunderstood me. I'm not ranting about IPODs - they're nice and well. I'm ranting that there is an obvious and cool application of this technology that they seem to be missing.
I was actually planning to buy a digital video cam, but the moment I thought about the possibility of HD-based one, I decided to postpone the whole thing and wait for them to appear.
It may take a year or two, but I'm pretty confident they'll be the new rage. And all necessary technology is already here.
I'd rather see a hard-drive-enabled video cam. No need for tapes, easy editing... don't feel like I have to continue.
And it better be 80 GB, not the measly 4GB like in some recent news...
I really believe that a device like this would win the market... it's beyond me why is nobody making them yet on mass scale.
Can't we make an airplane engine from this reactor?
It would take the atmospheric air, heat it by the energy of the nuclear reaction and release it for thrust. Same as burning fuel, but the energy source is not chemical.
Such a plane could fly for a LONG time on a single fuel load, and not having to carry excessive fuel weight, would make for quite an efficient design.
Would be a device to actually turn UP and DOWN the volume of a TV.
Back at the university, we had SGI workstations with a volume control applet that could be redirected by X to another display. Some guys just discovered digital music back then (it wasn't even MP3), and were constantly playing it.
So the solution was to abruptly jump the volume up and down, much to the bewilderment of the person affected. It was very hard to keep a straight face when he was looking at me... but after several such intrusions, the music was finally stopped.
The miniscule and unimportant fact that they Yahoo have thrown in an open license for it. And that everybody (including FOSS) can implement it at will.
OO languages aren't suitable for everything.
Right. But they are frigging darn good for GUI programming, and that's the problem in question.
Actually, it's hard to find a problem for which plain C would be a better fit, since you can always stick with the C subset of the language. Except maybe when a C++ compiler is not available.
Are far beyond helping the disabled.
Think driving, mouse pointing, surgery. And to top it off, computer games and [almost the same...;) ] jet fighter pilots.
<rant>I wonder if SUSE will be any better than Mandrake 10.1 on the laptop. It (Mandrake), like any previous version, has a huge problem with ACPI on Thinkpad R40 - it suspends just find, but never wakes up:(
I know it's probably a kernel problem... but still, they both *do* declare laptop support.
</rant>.
Second: The complexity sits where it is actually necessary - you need powerful control of what and when is printed (see below). The critical path of the code, the printing itself, is quite straightforward.
Fourth: Well, I could add some "#ifdef LOG_DISABLE". On the second thought, I'll do exactly that.
Your new point: you are close. Yes, it would be prohibitive, both space-wise and performance-wise, to print everything (in the case I describe, it can easily be 100K per cycle at maximal output).
But the point is not only that. I go to great lengths to make sure that only what you need to see is printed.
Your approach would require printing so much markup with the logging, that the content would drown, and it would need to be extremely readable to be effective. When something complex is going on in the program, you will need any bit of readability to get it.
So, the point of the article is not only to leave printfs inside, but to include a mechanism that would enable very precise control of what is printed and what isn't.
Point taken though. I'll see if I can improve the article to convey it better.
Second: because you don't need a much more advanced logging facility for the intended use.
Fourth: Whoa! That's easy: #define LOG(x) if (false) os. But actually, yes, I do ask people to not throw logging out once it's there. The reason it's not expensive when not used is that the branches in the "if(is_active())" do not change throughout the program, and thus are predicted very well and cost very little. I actually did measurements about the overhead of the mechanism and found it to be very small.
Fifth: We have used this methodology in several very complex projects, and with very good results. You are free to use other debugging methods if you wish.
And anyway, an article such as this is a fine way to research on how will people use my utility:)
You exactly missed the point. Everyone can write a logger, and ours is not an unusually smart one. The point is though, that *if you use loggers consistently, it'll be easy to debug*.
But oh well, why did I expect a Slashdot reader to RTFA.
Actually, it's not academic stuff and never meant to be. It's a simple article describing a nice methodology... and actually, it's not that much about the logger implementation (it isn't at all), but about how using debugging by logging consistently is a powerful technique.
Well, if you didn't RTFA, then you missed the point. The article is not about "oh, we wrote this wonderful logging mechanism". It's about the *methodology* of debugging almost exclusively by logging (as opposed to *sometimes* doing postmortem analysis by looking at the logs).
It's about leaving the logging code inside and improving it, rather than throwing it out shortly after it's used.
Architecturally, IA-64 is a very advanced architecture.
Ok, many people don't like it. And OK, it's complex. And OK, many people are making other quite good 64-bit processors.
If its competition was Power or MIPS, then OK, I'd say that the worse it is, let IA-64 die, but x86 (and x86-64 as well) is UGLY and laden with all kinds of OLD JUNK. Come on, it will be junked sooner or later. Granted, Intel can make high-performance x86s, but that at a price of devoting over 1/3 of the stages for decoding!
Or, let's put it that way. It is a Good Thing (TM) to have several different architectures. If all we'll be stuck with will be x86, it'll be quite sad.
The point is, expert user should never *need* to open any option. Then, the overwhelming set of "expert" options can easily stay (not to say that they should not be cleaned up in some places).
The point is, the system must Just Work (TM). Let's see (quoting from the article):
Font at top looks hard to read.
Fonts not anti-aliased by default.
Context sensitive help doesn't do anything.
Seems slow. Not enough indication that page was being found.
There are black arrows but no drop-downs.
Clicking home should open home folder.
Download manager did not give status of download.
I could go on and on and on. None of the above should need an option to get right, they are bugs that must be fixed. Who cares if, say, font configuration dialog is complex when fonts look OK 99.5% of the time.
Slashdot Mirror
Later, by fall of this year, the new boxed "2006" release will fully integrate Conectiva technology and Mandrakesoft online services into a new product. It will be released through traditional retail channels as well as by direct sale from Mandrakestore and Mandrakeclub, and will offer all support options and related services.
Note that there is no mention of a download option for Mandrakeclub. Am I missing something?
Mod parent up. Posted here, can't moderate. Seriously, the AC is right. FireFox has a reasonable implementation of tabs, the extensions are there and are OK (though I just cannot understand why tab drag&drop is not in the base install), but to say that they are the best implementation of tabs and that nothing more should be done in that area is a *HUGE* stretch.
Just to notice, this is not the original report on the issue. The first publication was a CACM article "The Homograph Attack", which featured a spoofed version of www.microsoft.com. See details here:http://www.cs.technion.ac.il/~gabr/papers/hom ograph.html.
Funny thing: at first, I included only the "here" as the text of the <a> tag. But then I thought: why should you trust to click a link if it can be homographed...
I have always had the problem on R40, where it suspends OK, but refuses to wake up 'cause it doesn't recognize the LID button. There was a kernel patch that should take care of that, but I never succeeded to get through it. Did you experience this problem? And, is it gone in 2.6.11?
While the MACs are a closed universe, the question still stands whether they will be compatible with the .doc format.
I don't know. Is a HD more power-hungry than a tape drive? Doesn't sound intuitive to me, but I may be wrong.
Any concrete data?
1. Rotational speed doesn't matter - video recording is a matter of sequential writing, and the density of this thing would more than compensate for RPM. Moreover, it's not that far-fetched to assume MPEG-2 encoding on such a device.
2. 80GB ought to be enough for quite a couple of hours o'video. Now correct me if I'm wrong, but I see no use of more than 10 hours off of any single event... and moreover, you wouldn't have enough storage to keep them on your comp anyway.
3. The whole point is that you will ultimately edit all the video on your computer. Said that, the only editing feature you need from the recorder is the *DELETE* button. All the rest shouldn't be done on the device itself.
DISCLAIMER: said all that, I'm currently not an owner of any video cam, and my opinion could change when I do get one.
Ok, you misunderstood me. I'm not ranting about IPODs - they're nice and well. I'm ranting that there is an obvious and cool application of this technology that they seem to be missing.
I was actually planning to buy a digital video cam, but the moment I thought about the possibility of HD-based one, I decided to postpone the whole thing and wait for them to appear.
It may take a year or two, but I'm pretty confident they'll be the new rage. And all necessary technology is already here.
I'd rather see a hard-drive-enabled video cam. No need for tapes, easy editing... don't feel like I have to continue.
And it better be 80 GB, not the measly 4GB like in some recent news...
I really believe that a device like this would win the market... it's beyond me why is nobody making them yet on mass scale.
I've upgraded to version 4, installed IE6 and I finally can access my bank's homepage. WOW!!!
One more reason to get off Windows.
Though, seems like the upgrade borked the fonts in MSWord. Ouch.
www.geyhole.com
Sounds good...
Can't we make an airplane engine from this reactor?
It would take the atmospheric air, heat it by the energy of the nuclear reaction and release it for thrust. Same as burning fuel, but the energy source is not chemical.
Such a plane could fly for a LONG time on a single fuel load, and not having to carry excessive fuel weight, would make for quite an efficient design.
Would be a device to actually turn UP and DOWN the volume of a TV.
Back at the university, we had SGI workstations with a volume control applet that could be redirected by X to another display. Some guys just discovered digital music back then (it wasn't even MP3), and were constantly playing it.
So the solution was to abruptly jump the volume up and down, much to the bewilderment of the person affected. It was very hard to keep a straight face when he was looking at me... but after several such intrusions, the music was finally stopped.
Act quick! Patent it!
The miniscule and unimportant fact that they Yahoo have thrown in an open license for it. And that everybody (including FOSS) can implement it at will.
OO languages aren't suitable for everything.
Right. But they are frigging darn good for GUI programming, and that's the problem in question.
Actually, it's hard to find a problem for which plain C would be a better fit, since you can always stick with the C subset of the language. Except maybe when a C++ compiler is not available.
Are far beyond helping the disabled. ;) ] jet fighter pilots.
Think driving, mouse pointing, surgery. And to top it off, computer games and [almost the same...
<rant>I wonder if SUSE will be any better than Mandrake 10.1 on the laptop. It (Mandrake), like any previous version, has a huge problem with ACPI on Thinkpad R40 - it suspends just find, but never wakes up :(
I know it's probably a kernel problem... but still, they both *do* declare laptop support. </rant>.
Fourth: Well, I could add some "#ifdef LOG_DISABLE". On the second thought, I'll do exactly that.
Your new point: you are close. Yes, it would be prohibitive, both space-wise and performance-wise, to print everything (in the case I describe, it can easily be 100K per cycle at maximal output).
But the point is not only that. I go to great lengths to make sure that only what you need to see is printed.
Your approach would require printing so much markup with the logging, that the content would drown, and it would need to be extremely readable to be effective. When something complex is going on in the program, you will need any bit of readability to get it.
So, the point of the article is not only to leave printfs inside, but to include a mechanism that would enable very precise control of what is printed and what isn't.
Point taken though. I'll see if I can improve the article to convey it better.
First: my fault ;)
Second: because you don't need a much more advanced logging facility for the intended use.
Fourth: Whoa! That's easy: #define LOG(x) if (false) os. But actually, yes, I do ask people to not throw logging out once it's there. The reason it's not expensive when not used is that the branches in the "if(is_active())" do not change throughout the program, and thus are predicted very well and cost very little. I actually did measurements about the overhead of the mechanism and found it to be very small.
Fifth: We have used this methodology in several very complex projects, and with very good results. You are free to use other debugging methods if you wish.
And anyway, an article such as this is a fine way to research on how will people use my utility :)
You exactly missed the point. Everyone can write a logger, and ours is not an unusually smart one. The point is though, that *if you use loggers consistently, it'll be easy to debug*.
But oh well, why did I expect a Slashdot reader to RTFA.
Actually, it's not academic stuff and never meant to be. It's a simple article describing a nice methodology... and actually, it's not that much about the logger implementation (it isn't at all), but about how using debugging by logging consistently is a powerful technique.
Well, if you didn't RTFA, then you missed the point. The article is not about "oh, we wrote this wonderful logging mechanism". It's about the *methodology* of debugging almost exclusively by logging (as opposed to *sometimes* doing postmortem analysis by looking at the logs).
It's about leaving the logging code inside and improving it, rather than throwing it out shortly after it's used.
Architecturally, IA-64 is a very advanced architecture.
Ok, many people don't like it. And OK, it's complex. And OK, many people are making other quite good 64-bit processors.
If its competition was Power or MIPS, then OK, I'd say that the worse it is, let IA-64 die, but x86 (and x86-64 as well) is UGLY and laden with all kinds of OLD JUNK. Come on, it will be junked sooner or later. Granted, Intel can make high-performance x86s, but that at a price of devoting over 1/3 of the stages for decoding!
Or, let's put it that way. It is a Good Thing (TM) to have several different architectures. If all we'll be stuck with will be x86, it'll be quite sad.
The point is, the system must Just Work (TM). Let's see (quoting from the article):
- Font at top looks hard to read.
- Fonts not anti-aliased by default.
- Context sensitive help doesn't do anything.
- Seems slow. Not enough indication that page was being found.
- There are black arrows but no drop-downs.
- Clicking home should open home folder.
- Download manager did not give status of download.
I could go on and on and on. None of the above should need an option to get right, they are bugs that must be fixed. Who cares if, say, font configuration dialog is complex when fonts look OK 99.5% of the time.