Talking out of ass mode activated. No lighters please.
One issue which hasn't been raised (here, that is) is how much processor time an application gets. In a one-to-many implementation, it didn't matter how many threads an application spawned, since the application is the unit of schedule. How it divides its cycles across threads is its own concern.
In the one-to-one model, the opposite is true; if an application has hundreds of threads, and each one is scheduled independently, the application could easily eat up 75% of all the cycles of the machine. (leading the user to conclude that one-to-one scheduling is slow)
I'm sure the powers that be have thought about this and have some sort of scheduling policy for this, but of course that makes the scheduling alg that much more expensive. Just thought I'd bring it to attention
So I think the 2 phase scheduling of Irix is pretty neat (as heard third hand in an earlier post above).
The thing is that 2 or 10 times speed up is great, on the java side. But java is kinda known to have all sorts of inefficiencies (sp?).
however, 20% on a [presumably] well tuned peice of code like the scheduler if fantastic. This benefits not only java, but all thread intensive processes.
Harking back to the paper; I believe that a one-to-one model is the way to go, but with a poilicy that favours threads that already have their memory space "loaded". Then you don't take the process switch penalty to the caches and TLBs. (being careful not to starve any process, of course).
I've only had time to skim the paper, so maybe this is what they've done.
There was a case someone posted tangentially a while ago pointing out that some linux index fund was using the wrong symbol for redhat (REDH instead of RHAT), so they were off by so many percent.
yeah, and I want johan back. So maybe we should get the pips (people in power) to put a timeout on uids, so that if noone has used a name for a while (or ever, even) it kinda reverts back to the pool of usable names.
The while would have to be long, tho, to avoid identity confusion.
Re:Design of Mozilla must address fears of busines
on
Mozilla Status Update
·
· Score: 1
Bit of a pet peeve here, so bear with me:
Java script should never be necessary to use a site. Hotmail recently made it necessary, so I've quit recommending it.
Java script should only be an enhancement (for example, checking for proper syntax in form fields, or perhaps doing mouseovers). At all times, an ultra-dumb browser should be correct, if not pretty. This goes back to the argument that anyone who trusts the client to do the right thing deserves the reputation they'll get.
end of rant.
Oh, and with dynamically generated html, this is not that hard to do.
But ok. Maybe I'm talking out of my ass again. Can anyone suggest a web-solution that cannot be redesigned according to the above?
That's assuming you can reprogram the FPGA quickly enough to be able to task switch the hardware. To make up for the reconfiguration time, you'd have to guarantee a significant speed up vs the (likely higher MHz) hardwired processor. And you'll also have to amortize the cost of the JIT.
So yes, possible, but I'd need some convincing before I buy it as feasable.
To quote someone: "post or moderate? Post or moderate?"
Well, I'd have to disagree with you there, Norm.
I've heard that the LCD is the single biggest power hog on there. But you're right, I'd like to see a less power-hungry cpu. But I don't need no stinkin' multimedia device.
What I'd like to see is someone manufacture an older cpu (as I can't really justify needing more than a P166 (if even) equiv in my laptop, and would gladly trade battery life for speed. I suspect that many would agree with me) using modern fabs, thus making them small, cool, and power lean.
Make the back of the display white/detachable/translucent, so that I can use ambient light when availible.
Basically, if you look at the triumvariate (hoping I'm using the word correctly) of display, speed, and batterylife, the display and batterylife have been mostly constant througout the evolution of the laptop, whilst speed has steadily increased. I don't want that. I'd rather see steady increases in batterylife, and only incidental improvements in the other two.
So it seems to me that starving artists would be all for some sort of (and I hesitate to use the term even) Divx like system where it was free (and encouraged) to give away copies of a song (or software in general). Each song could then be played free during some trial phase, after which you would be required to pay for it.
Divx tried this and was burned completely. I'm not really sure why. I think it was just a PR bungle, really. We are all happy renting movies (I personally don't own a single one), so I don't see why people got such a bug up their asses about Divx, but I digress.
The goals are as follows: we want to separate distribution and payment. Furthermore, different payment schedules are needed. For example, for a peice of software you'll use alot, you'd rather pay once, and have unlimited use. For an album of songs from an uneven artist, you'd rather pay-to-play. Maybe you could have an evaluation period.
By separating distribution and payment, we can get the middle men out of the picture. Sony, Geffen, and whonot are not really in the business of distributing cds; they only have to do that to enable their real business: to sell music.
Unfortunately, CDs have huge capital investments that need to be made (not so much in production, but sales and distribution), so they can only bet on sure things (to the detriment of smaller artists everywhere). This is of course where digital music comes in. A secure storage scheme would leverage the power of bits (to invoke negroponte). The internet has made distribution free. Give copies to your friends. Payment is what these companies should focus on. The same payment infrastructure would work for all acts, so once again, the marginal cost of signing up an act is miniscule.
So in summarium: a secure music format would benefit everyone, as the big companies would be free to take care of payments (and the necessary multiply redunant 100% uptime systems necessary to keep things humming). Distribution would be up to marketing companies or word of mouth. The barrier to entry would be so low that everyone could play.
Of course, the format would have to be uncrackable for the companies to bet the farm like this, so it would likely require encrypted-signal-to-output-device. A bit of infrastructure investment, then. Of course, your output device would have to be net enabled as well. But I believe it is inevitable.
I spoke to a woman who works at the MIT patent office a couple of months ago. She was bitching about how on fridays, the DNA people drop of the list of all the genes that had been sequenced that week, to be patented.
So as far as I understood what she said, that is exactly what they are doing. Hopefully, it'll never hold up in court. After all, the legal system has proven itself to be a sagacious interpreter of high-tech law.
Some people will always be more or less mature than the norm. The US however, has a culture of accommodating itself to the lower common denominator rather than the higher (idiocy in the laws over here attest to this), so children are all assumed to be immature until the greatest fraction of them are past the bar. Unfortunately, there is a feedback effect, so turning it into a bit of a self-fullfilling prophecy.
blah blah
Just remove the middleman -- read reuters
on
Live or Memorex?
·
· Score: 1
Yup.
The big news centers are coming to the end of their 15 minutes of fame. As soon as we have pseudo-AI good enough to create our own news casts from a wide variety of sources, traditional news desks will become little more than editorial services that point our news-bots towards interesting information (hey! does this sound like a web site you've been to recently?).
It's easy to see: if there are alot of information feeds, (many more than just reuters, AP, ABC) then it will be rather easy to figure out what really happened; to strip away any spin or advertising or whatever, just average out the originals (or something like that)
ramble ramble. I guess all I really wanted to point out that as long as there is a recognised need for disintermediating the news, all we need to have is easy information access and uploading, and from there it is easy to design a system that will assign reputation points to trustworthy sources and spam points to those who consistently color it.
It was the first color television standard for gods sake.
This is the paradox of early lock-in to standards. It happened here in the states for cell phones too. Europe got to see what the states did wrong, so now they get a wide choice of cool GSMs while we have to diddle along with crap tech and boring phones. But you all know this; it's not who's got the best tech, it's who can entrench it first. After that, monopsonist powers allow you to write all the rules.
So we finally get to play with display postscript? Cool!
PS: PDF is basically a partially evaluated version of postscript, as far as I can tell. I don't think it is a fully programmable language, but I may be wrong on that account.
I completely disagree. As a disclaimer, these are totally my opinions, but every so often, other people agree with those too. or maybe not. anyways:
We don't need a close button on any window. Closing is done so seldomly that it deserves to be on a contextual menu -- right click on window frame to close. You don't want to make it easy, as it is seldomly used and irreversible. That is not true of iconisation, movement, or resizing -- three very common operations.
Iconisation should be a single button. Put it on the left. Since we won't be sending any input to the window after iconisation, the "above the scroll bar" argument doesn't apply. Reiconising is a bit of a hassle, so make it unlikely to hit by mistake by putting it far away from the scrollbar.
Moving the window is a common fuction -- hence the entire window frame should be usable to move the window, as that is a common task. It really anoys me when I try to move a window and end up resizing it.
This leaves only one common task -- resizing / maximising. The maximise button could be ontop of the scroll bar for the already cited locality reasons. It is after scrolling a bit that we decide to maximise the window. Hrm. So actually, it might make sense to put a maximise button lower right, underneath the scrollbar. click to maximise, drag to resize perhaps. yeah, I'd like that.
So in summarium, apple had it almost 100 % right in my opinion. The only mistake was putting a close button instead of an iconise, and the maximise on top.
The FFTW works (If I recall correctly) by basically figuring out the proper order of hierarchical decompositions to use. An analogy is quick sort, which also is recursive. We all know that the best quick-sort implementation is to switch to insertion sort when the length is less than 5ish, cause quick sort's constant factors outweigh insertion sort's asympotic ones for short lists.
FFTs are also recursive, and FFTW is basically a really smart way to derive at which point to start using various FT alorithms. (IIRC yadda yadda).
There is no reason why the same ideas couldn't be applied to wavelets, as it appears (and I am totally guessing here) that they too are recursive.
Driving on their roads is a privelege. Build your own roads and keep them separate from the gvmt's, and you can drive on them all you want, licence or no.
Google works on the idea that pages that have a lot of incoming links are authorities on what they discuss, so they should be ranked highly.
A modification of this is to not only rank a site's authoritativeness (eh?) this way, but also what kind of content it has. So if 10K geeks all have homepages that include the words "geek" and "computer" and also point to/., it is reasonable to assume that regardless of actual content today,/. typically is a good result to return for the search "geek sites".
Of course, some of those homepages will also have the words "tennis" and "knitting", that will be spuriously attributed to/., but the idea is that they will be outliers, and drown in the noise.
This basically is keyword indexing, but the keywords are dynamically determined, rather than using the broken meta tags.
The big problem with this approach is implementation; the association tables are likely to be huge.
Also, you assume a large sample size, so that the outliers will cancel.
ya know, I don't quite agree here. Wysiwyg email is what people want, and it might as well be done with html. The problem is that full-fledged html will have observable effects when you read it.
The better solution would be to do use multi-attachment mime, and have the email client restricted to only displaying images and components that are attachments of the message.
All we need is a small modification to html to specify message local information -- something like
Hrm. I dunno. I bought the newish aiwa (w/ the blue back light remote control on the headphones and 40 hours batt life) recorder/player, and Esp on massive attack's deep bass voice-overs, I thought I heard quite clear artifacts of compression. Could be my imagination tho. Used the optical cable, so digital transfer all the way.
But BTW, a question about ATRAC:Do all ATRAC implementations compress the same bitstream identically?Is it merely a file format, like MP3, or an algorithm for generating that file format?
What's I'm looking for is an excuse to blame the cheap (presumably) encoder in my aiwa and be able to rest assured that professional equipment would do a better job (not that I'd go through the hassle -- the quality is still quite acceptable -- but I'd like to know it's there).
'cause it was the closest. Frankly I don't care who writes or develops my browser; what Io care about is that it runs ALL the sites that I want to visit. And this means (shudder) shockwave and (gasp) java and (tremble) javascript.
Now I'll state it plainly: I really wish webmasters would stick to plain html, and use dynamic content generation to implement gimmicks.
However, it seems that 90% of webmasters (apologies to the 10% of you who don't suck) don't realise that anyone would access their site using a different os/browser/plugin setup than they have. Many of my old friends from college are webmasters, and that wouldn't be so bad if they weren't all business majors with very few clues about computers.
But end of second rant of the day (see Minidisc story for the first).
So realising that it's impossible to educate all content creators, it is necessary for me to get a browser that understands everything they put out. and that means plugins.
I think perhaps Wine is the only realistic option here.
Slashdot Mirror
Talking out of ass mode activated. No lighters please.
One issue which hasn't been raised (here, that is) is how much processor time an application gets. In a one-to-many implementation, it didn't matter how many threads an application spawned, since the application is the unit of schedule. How it divides its cycles across threads is its own concern.
In the one-to-one model, the opposite is true; if an application has hundreds of threads, and each one is scheduled independently, the application could easily eat up 75% of all the cycles of the machine. (leading the user to conclude that one-to-one scheduling is slow)
I'm sure the powers that be have thought about this and have some sort of scheduling policy for this, but of course that makes the scheduling alg that much more expensive. Just thought I'd bring it to attention
So I think the 2 phase scheduling of Irix is pretty neat (as heard third hand in an earlier post above).
Well, I can't agree with you there norm.
The thing is that 2 or 10 times speed up is great, on the java side. But java is kinda known to have all sorts of inefficiencies (sp?).
however, 20% on a [presumably] well tuned peice of code like the scheduler if fantastic. This benefits not only java, but all thread intensive processes.
Harking back to the paper; I believe that a one-to-one model is the way to go, but with a poilicy that favours threads that already have their memory space "loaded". Then you don't take the process switch penalty to the caches and TLBs. (being careful not to starve any process, of course).
I've only had time to skim the paper, so maybe this is what they've done.
There was a case someone posted tangentially a while ago pointing out that some linux index fund was using the wrong symbol for redhat (REDH instead of RHAT), so they were off by so many percent.
I grinned.
yeah, and I want johan back. So maybe we should get the pips (people in power) to put a timeout on uids, so that if noone has used a name for a while (or ever, even) it kinda reverts back to the pool of usable names.
The while would have to be long, tho, to avoid identity confusion.
grin!
Bit of a pet peeve here, so bear with me:
Java script should never be necessary to use a site. Hotmail recently made it necessary, so I've quit recommending it.
Java script should only be an enhancement (for example, checking for proper syntax in form fields, or perhaps doing mouseovers). At all times, an ultra-dumb browser should be correct, if not pretty. This goes back to the argument that anyone who trusts the client to do the right thing deserves the reputation they'll get.
end of rant.
Oh, and with dynamically generated html, this is not that hard to do.
But ok. Maybe I'm talking out of my ass again. Can anyone suggest a web-solution that cannot be redesigned according to the above?
That's assuming you can reprogram the FPGA quickly enough to be able to task switch the hardware. To make up for the reconfiguration time, you'd have to guarantee a significant speed up vs the (likely higher MHz) hardwired processor. And you'll also have to amortize the cost of the JIT.
So yes, possible, but I'd need some convincing before I buy it as feasable.
To quote someone: "post or moderate? Post or moderate?"
Well, I'd have to disagree with you there, Norm.
I've heard that the LCD is the single biggest power hog on there. But you're right, I'd like to see a less power-hungry cpu. But I don't need no stinkin' multimedia device.
What I'd like to see is someone manufacture an older cpu (as I can't really justify needing more than a P166 (if even) equiv in my laptop, and would gladly trade battery life for speed. I suspect that many would agree with me) using modern fabs, thus making them small, cool, and power lean.
Make the back of the display white/detachable/translucent, so that I can use ambient light when availible.
Basically, if you look at the triumvariate (hoping I'm using the word correctly) of display, speed, and batterylife, the display and batterylife have been mostly constant througout the evolution of the laptop, whilst speed has steadily increased. I don't want that. I'd rather see steady increases in batterylife, and only incidental improvements in the other two.
So it seems to me that starving artists would be all for some sort of (and I hesitate to use the term even) Divx like system where it was free (and encouraged) to give away copies of a song (or software in general). Each song could then be played free during some trial phase, after which you would be required to pay for it.
Divx tried this and was burned completely. I'm not really sure why. I think it was just a PR bungle, really. We are all happy renting movies (I personally don't own a single one), so I don't see why people got such a bug up their asses about Divx, but I digress.
The goals are as follows: we want to separate distribution and payment. Furthermore, different payment schedules are needed. For example, for a peice of software you'll use alot, you'd rather pay once, and have unlimited use. For an album of songs from an uneven artist, you'd rather pay-to-play. Maybe you could have an evaluation period.
By separating distribution and payment, we can get the middle men out of the picture. Sony, Geffen, and whonot are not really in the business of distributing cds; they only have to do that to enable their real business: to sell music.
Unfortunately, CDs have huge capital investments that need to be made (not so much in production, but sales and distribution), so they can only bet on sure things (to the detriment of smaller artists everywhere). This is of course where digital music comes in. A secure storage scheme would leverage the power of bits (to invoke negroponte). The internet has made distribution free. Give copies to your friends. Payment is what these companies should focus on. The same payment infrastructure would work for all acts, so once again, the marginal cost of signing up an act is miniscule.
So in summarium: a secure music format would benefit everyone, as the big companies would be free to take care of payments (and the necessary multiply redunant 100% uptime systems necessary to keep things humming). Distribution would be up to marketing companies or word of mouth. The barrier to entry would be so low that everyone could play.
Of course, the format would have to be uncrackable for the companies to bet the farm like this, so it would likely require encrypted-signal-to-output-device. A bit of infrastructure investment, then. Of course, your output device would have to be net enabled as well. But I believe it is inevitable.
Johan
I spoke to a woman who works at the MIT patent office a couple of months ago. She was bitching about how on fridays, the DNA people drop of the list of all the genes that had been sequenced that week, to be patented.
So as far as I understood what she said, that is exactly what they are doing. Hopefully, it'll never hold up in court. After all, the legal system has proven itself to be a sagacious interpreter of high-tech law.
Some people will always be more or less mature than the norm. The US however, has a culture of accommodating itself to the lower common denominator rather than the higher (idiocy in the laws over here attest to this), so children are all assumed to be immature until the greatest fraction of them are past the bar. Unfortunately, there is a feedback effect, so turning it into a bit of a self-fullfilling prophecy.
blah blah
Yup.
The big news centers are coming to the end of their 15 minutes of fame. As soon as we have pseudo-AI good enough to create our own news casts from a wide variety of sources, traditional news desks will become little more than editorial services that point our news-bots towards interesting information (hey! does this sound like a web site you've been to recently?).
It's easy to see: if there are alot of information feeds, (many more than just reuters, AP, ABC) then it will be rather easy to figure out what really happened; to strip away any spin or advertising or whatever, just average out the originals (or something like that)
ramble ramble. I guess all I really wanted to point out that as long as there is a recognised need for disintermediating the news, all we need to have is easy information access and uploading, and from there it is easy to design a system that will assign reputation points to trustworthy sources and spam points to those who consistently color it.
blah blah
This is the paradox of early lock-in to standards. It happened here in the states for cell phones too. Europe got to see what the states did wrong, so now they get a wide choice of cool GSMs while we have to diddle along with crap tech and boring phones. But you all know this; it's not who's got the best tech, it's who can entrench it first. After that, monopsonist powers allow you to write all the rules.
cvs servers are good for this sort of thing. A "Here ya go. The current source. Use at your own risk" sort of deal. Hey it works for the E people.
So we finally get to play with display postscript?
Cool!
PS: PDF is basically a partially evaluated version of postscript, as far as I can tell. I don't think it is a fully programmable language, but I may be wrong on that account.
I completely disagree. As a disclaimer, these are totally my opinions, but every so often, other people agree with those too. or maybe not. anyways:
We don't need a close button on any window. Closing is done so seldomly that it deserves to be on a contextual menu -- right click on window frame to close. You don't want to make it easy, as it is seldomly used and irreversible. That is not true of iconisation, movement, or resizing -- three very common operations.
Iconisation should be a single button. Put it on the left. Since we won't be sending any input to the window after iconisation, the "above the scroll bar" argument doesn't apply. Reiconising is a bit of a hassle, so make it unlikely to hit by mistake by putting it far away from the scrollbar.
Moving the window is a common fuction -- hence the entire window frame should be usable to move the window, as that is a common task. It really anoys me when I try to move a window and end up resizing it.
This leaves only one common task -- resizing / maximising. The maximise button could be ontop of the scroll bar for the already cited locality reasons. It is after scrolling a bit that we decide to maximise the window. Hrm. So actually, it might make sense to put a maximise button lower right, underneath the scrollbar. click to maximise, drag to resize perhaps. yeah, I'd like that.
So in summarium, apple had it almost 100 % right in my opinion. The only mistake was putting a close button instead of an iconise, and the maximise on top.
Johan
The FFTW works (If I recall correctly) by basically figuring out the proper order of hierarchical decompositions to use. An analogy is quick sort, which also is recursive. We all know that the best quick-sort implementation is to switch to insertion sort when the length is less than 5ish, cause quick sort's constant factors outweigh insertion sort's asympotic ones for short lists.
FFTs are also recursive, and FFTW is basically a really smart way to derive at which point to start using various FT alorithms. (IIRC yadda yadda).
There is no reason why the same ideas couldn't be applied to wavelets, as it appears (and I am totally guessing here) that they too are recursive.
just to pick nits, but I read
"compressed encrypted file"
as first encrupted and then compressed.
You mean the opposite, right?Cause else I can't follow your reasoning at all.
Driving on their roads is a privelege. Build your own roads and keep them separate from the gvmt's, and you can drive on them all you want, licence or no.
Think Google.
/., it is reasonable to assume that regardless of actual content today, /. typically is a good result to return for the search "geek sites".
/., but the idea is that they will be outliers, and drown in the noise.
Google works on the idea that pages that have a lot of incoming links are authorities on what they discuss, so they should be ranked highly.
A modification of this is to not only rank a site's authoritativeness (eh?) this way, but also what kind of content it has. So if 10K geeks all have homepages that include the words "geek" and "computer" and also point to
Of course, some of those homepages will also have the words "tennis" and "knitting", that will be spuriously attributed to
This basically is keyword indexing, but the keywords are dynamically determined, rather than using the broken meta tags.
The big problem with this approach is implementation; the association tables are likely to be huge.
Also, you assume a large sample size, so that the outliers will cancel.
Johan
also has a second definition -- example follows
The NSA wasn't giving out any desinformation, but was more than happy to provide skipjackinformation.
Johan
$@%#!
for chissakes, when i specify posting with
plain text, don't strip my psuedo html -- escape it instead.
meant to write
openbracket img src="mime://attachment4.png" closebacket
as the example
ya know, I don't quite agree here. Wysiwyg email is what people want, and it might as well be done with html. The problem is that full-fledged html will have observable effects when you read it.
The better solution would be to do use multi-attachment mime, and have the email client restricted to only displaying images and components that are attachments of the message.
All we need is a small modification to html to specify message local information -- something like
Johan
Hrm. I dunno. I bought the newish aiwa (w/ the blue back light remote control on the headphones and 40 hours batt life) recorder/player, and Esp on massive attack's deep bass voice-overs, I thought I heard quite clear artifacts of compression. Could be my imagination tho. Used the optical cable, so digital transfer all the way.
But BTW, a question about ATRAC:Do all ATRAC implementations compress the same bitstream identically?Is it merely a file format, like MP3, or an algorithm for generating that file format?
What's I'm looking for is an excuse to blame the cheap (presumably) encoder in my aiwa and be able to rest assured that professional equipment would do a better job (not that I'd go through the hassle -- the quality is still quite acceptable -- but I'd like to know it's there).
Johan
'cause it was the closest. Frankly I don't care who writes or develops my browser; what Io care about is that it runs ALL the sites that I want to visit. And this means (shudder) shockwave and (gasp) java and (tremble) javascript.
Now I'll state it plainly: I really wish webmasters would stick to plain html, and use dynamic content generation to implement gimmicks.
However, it seems that 90% of webmasters (apologies to the 10% of you who don't suck) don't realise that anyone would access their site using a different os/browser/plugin setup than they have. Many of my old friends from college are webmasters, and that wouldn't be so bad if they weren't all business majors with very few clues about computers.
But end of second rant of the day (see Minidisc story for the first).
So realising that it's impossible to educate all content creators, it is necessary for me to get a browser that understands everything they put out. and that means plugins.
I think perhaps Wine is the only realistic option here.
Johan