someone mod up the parent, they are correct, the mensa babe, despite their mensa membership, is wrong. MTBF of 20 drives, one failling each year is (Sigma(n=1 to 20){n})/20 which is 10.5 years.
A quick thought experiment should make it obvious that for a series of numbers (eg number of years between failure) where the highest number is n, that the mean of these numbers could never be n.
IIRC the StrongARM and PXA (XScale) have a framebuffer built in to them. not sure on how they're programmed though. (there must be docs on intel.com somewhere)
You should try this shit before dismissing it so casually. My spam problem has gone from being intolerable (20-30 / day) to just one spam message in the last 2 months thanks to TMDA.
But i'm not doubting it stops spam getting through. In fact i'm reasonably convinced its the best technical answer to spam existing at the moment. My problems are with complicating email by using C-R, and i believe spammers would adapt anyway, hence bringing us back to blacklists anyway.
ah... you mean you'd try a dictionary attack against my/whitelist/. Now i get you. Well, then you'll fail - i wouldnt have any clubi.ie addresses on my whitelist.:)
Dictionary attacks against recipient addresses are quite feasible - you already know the domain part. Dict attacks against whitelists though have a much much wider space to crack. Your chances of brute forcing a match are far far slimmer than for the recipient case.
As someone wrote on linux-kernel, if there is code in the linux kernel and in SCO which is identical, it is probably because/SCO/ coders once copied code from linux and incorporated it into SCO. Scroll down a few years to present, SCO hires consultants to compare linux code to SCO's own and hey presto "look its the same code!".
Also, a heavy hint was dropped on linux-kernel by a former SCO employee (iirc) that if one were to look very carefully at the support for a certain filesystem (*cough* 0x83) in the SCO kernel that one would find an example of the type of copying above.
Actually, you're working from incorrect assumptions.
- spammers arent traceable, we dont know who they are
- if TMDA made them come out into the open, then we could get them.
They are traceable. The spammers are by and large mostly known. The problem is there is no broad legal consensus against spam and there is no strong economic disincentive against spamming for either the spammers or the pink-contract ISPs. You cant "get them", unless you blacklist ISPs (but hey, we can already do that and do, so why did we need TMDA?)
Your vision of jpeg or turing-test challenge-response systems for email is simply frightening. Its holds promise of an ever escalating C-R war with spammers, perhaps ultimately destroying the convenience of email.
The problem is that criminalising drugs/users/ does absolutely nothing to solve the problem.
It opens up a huge market to organised crime, giving very unsavoury characters a lot of funds, and allowing vast networks of criminals to be built up. This then requires allocation of massive amounts of policing resources - which is a significant cost economically, and also in terms of other areas from which policing resources are diverted.
In the meantime, you havnt really solved any problems relating to drugs/usage/. (but you've got a burgeoning population that again is a drain on resources, and also quite a few otherwise law-abiding citizens who now have a criminal record).
The whole thing needs a rethink really. Its a problem, and the current way of handling it just exacerbates it. Precisely what the answer/is/ isnt clear, much more education, much more preventative action - but criminalisation of/users/ is not part of the answer imo.
X on Qtopia: ah, neat. ie an Xnest server ported to Qtopia? (didnt know it existed - sorry).
2. Well, what do you mean by real handwriting recognition?
The trouble is you want the computer to magically recognise whatever you write. but, that just isnt going to happen for now. There needs to be some formal specification for character recognition, and most systems have opted for 'stroke' recognition. Note that one of the biggest reasons for this is that hardware limitations/interfaces make this the most practical recognition system. Ie its much easier to limit each char to a single stroke (one set of pen-down/pen-up events), than try work out how to recognise character bounds if multiple 'strokes' are allowed -> "ok, did the user just dot his 'i' or did that second tap mean a full stop? hmm.." - far too error-prone, and even single-stroke recognition isnt that free of errors either. However, you can at least learn how to write the strokes in the best way so that the software can reliable recognise them.
Xstroke, imo, is pretty good. You can draw anywhere on the screen, and once you get the hang of it you can work reasonably well, even with the CLI. Speed: its pretty good, it does slow down on occassion - this usually manifests itself in the 'stroke' graphic on screen drawing slowly, not in character recognition. i find that renicing it to -3 helps a/lot/ (suggesting the problem is more with linux being deficient in scheduling time for Xstroke and Xipaq when its needed, than in Xstroke itself. i renice Xipaq to -10 too.).
Yes, familiar can run on Zaurus. You'll have to hunt around for instructions though, or ask on the irc.freenode.net#gpe irc channel - i know that at least two of the more active developers have Zauruses (Zaurii?) (the C700).
Familiar runs its own kernel. I guess you'd have to keep your sharp kernel and run that. SD will (it seems) never be supported openly under linux, as the consortium controlling the specs will not release them.
Familiar pro-ipaq? Well, handhelds.org was setup by Compaq:)
Where did you get 'two' from? I gave 68k and x86 as examples, but binaries could be arbitrarily fat - another respondent gave examples of other arches. Additionally, i have a vague idea that you could 'strip' fat binaries of unneeded architecture code - not 100% sure on this.
Or what about the even cooler (but not as mature) GTK+ 2 based GPE? X based so when at home you can have your apps display to your desktop and make use of a real keyboard. Though the graffiti-like Xstroke app GPE uses is excellent and so you might not miss your desktop keyboard:).
As the author he is under/no/ obligation to provide source, he merely chooses to do so.
I think the answer is:
- Provide source under the GPL
- Provide certified binaries for a fee to cover the certification cost, and/not/ under GPL. Eg, some licence licence that allows use for free, and making of copies for ones/own/ use, but redistribution forbidden.
He is the copyright holder i presume, so he can do what he wants with the licences.
Apple (well NeXT) solved that problem already. OpenStep (cant both to capitalise it correctly) ran on both 68k and x86 machines, and OpenStep software could be compiled to be 'fat', ie including both 68k and x86 machine code so it could be installed and executed on either architecture. Wasnt very popular, but disk space wasnt as cheap in those days as it is now.
Apple must still have that code lying around somewhere.
if some GPL code makes its way its something else... its is GPLed
This isnt true. If GPL code is incorporated into proprietary code, then it is a GPL licence violation (providing 'derived work' holds true). Licence violations mean you can seek redress, either by settling privately with the violator, or by getting a judge to rule in your favour. Redress could consist of damages and the violator excising the GPL code from his app, and/or even relicensing of the derived work under GPL.
But it is by no means automatic. What happens when GPL licence is violated is for the 2 parties to settle between themselves or, if they can not come to an amicable settlement, a judge to decide.
that's what we're discussing:). heap backed by mmap(): that is only true if the allocations are above a certain size according to the glibc info pages.
Yes, indeed, i think i referred to that in the last paragraph.
Note though that the threshold for glibc using mmap() is 128k, most allocations wont be anywhere near that large and will be allocated from heap. mmap() allocations have a performance overhead.
X maps the entire video ram. So if you have an 8MB card, then 8MB of X's supposed memory usage is actually mapped video ram. X can use the remaining 5 MB (eg 3MB used for display from your example) of video ram to store pixmaps, etc.. (google for XAA - X acceleration architecture iirc). If you have a 32MB card, then X will be at least 32MB in size, if you have a super duper 128MB card, X will be at least 128MB in size - just because of the VRAM mapping.
Slashdot Mirror
nice try, but if something fails and you then fix it, it has still failed. :)
urg... with proviso that at least one of the series of numbers is not equal to n.
someone mod up the parent, they are correct, the mensa babe, despite their mensa membership, is wrong. MTBF of 20 drives, one failling each year is (Sigma(n=1 to 20){n})/20 which is 10.5 years.
A quick thought experiment should make it obvious that for a series of numbers (eg number of years between failure) where the highest number is n, that the mean of these numbers could never be n.
like this cluster of Compaq iPaqs?
Well, i suspect the framebuffer on SA1100 is very simple, a linear framebuffer mapped into kernel space - not accellerated.
IIRC the StrongARM and PXA (XScale) have a framebuffer built in to them. not sure on how they're programmed though. (there must be docs on intel.com somewhere)
You should try this shit before dismissing it so casually. My spam problem has gone from being intolerable (20-30 / day) to just one spam message in the last 2 months thanks to TMDA.
But i'm not doubting it stops spam getting through. In fact i'm reasonably convinced its the best technical answer to spam existing at the moment. My problems are with complicating email by using C-R, and i believe spammers would adapt anyway, hence bringing us back to blacklists anyway.
ah... you mean you'd try a dictionary attack against my /whitelist/. Now i get you. Well, then you'll fail - i wouldnt have any clubi.ie addresses on my whitelist. :)
Dictionary attacks against recipient addresses are quite feasible - you already know the domain part. Dict attacks against whitelists though have a much much wider space to crack. Your chances of brute forcing a match are far far slimmer than for the recipient case.
As someone wrote on linux-kernel, if there is code in the linux kernel and in SCO which is identical, it is probably because /SCO/ coders once copied code from linux and incorporated it into SCO. Scroll down a few years to present, SCO hires consultants to compare linux code to SCO's own and hey presto "look its the same code!".
Also, a heavy hint was dropped on linux-kernel by a former SCO employee (iirc) that if one were to look very carefully at the support for a certain filesystem (*cough* 0x83) in the SCO kernel that one would find an example of the type of copying above.
Irrelevant.. i wouldnt have /you/ whitelisted.
Actually, you're working from incorrect assumptions.
- spammers arent traceable, we dont know who they are
- if TMDA made them come out into the open, then we could get them.
They are traceable. The spammers are by and large mostly known. The problem is there is no broad legal consensus against spam and there is no strong economic disincentive against spamming for either the spammers or the pink-contract ISPs. You cant "get them", unless you blacklist ISPs (but hey, we can already do that and do, so why did we need TMDA?)
Your vision of jpeg or turing-test challenge-response systems for email is simply frightening. Its holds promise of an ever escalating C-R war with spammers, perhaps ultimately destroying the convenience of email.
the spammer would have to know of an address the recipient has whitelisted.
The problem is that criminalising drugs /users/ does absolutely nothing to solve the problem.
/usage/. (but you've got a burgeoning population that again is a drain on resources, and also quite a few otherwise law-abiding citizens who now have a criminal record).
/is/ isnt clear, much more education, much more preventative action - but criminalisation of /users/ is not part of the answer imo.
It opens up a huge market to organised crime, giving very unsavoury characters a lot of funds, and allowing vast networks of criminals to be built up. This then requires allocation of massive amounts of policing resources - which is a significant cost economically, and also in terms of other areas from which policing resources are diverted.
In the meantime, you havnt really solved any problems relating to drugs
The whole thing needs a rethink really. Its a problem, and the current way of handling it just exacerbates it. Precisely what the answer
THC (the active ingredient in mariuana) isn't addictive
Can you cite a reference to back this up, because from personal observational evidence i would tend to think it most definitely is.
X on Qtopia: ah, neat. ie an Xnest server ported to Qtopia? (didnt know it existed - sorry).
/lot/ (suggesting the problem is more with linux being deficient in scheduling time for Xstroke and Xipaq when its needed, than in Xstroke itself. i renice Xipaq to -10 too.).
2. Well, what do you mean by real handwriting recognition?
The trouble is you want the computer to magically recognise whatever you write. but, that just isnt going to happen for now. There needs to be some formal specification for character recognition, and most systems have opted for 'stroke' recognition. Note that one of the biggest reasons for this is that hardware limitations/interfaces make this the most practical recognition system. Ie its much easier to limit each char to a single stroke (one set of pen-down/pen-up events), than try work out how to recognise character bounds if multiple 'strokes' are allowed -> "ok, did the user just dot his 'i' or did that second tap mean a full stop? hmm.." - far too error-prone, and even single-stroke recognition isnt that free of errors either. However, you can at least learn how to write the strokes in the best way so that the software can reliable recognise them.
Xstroke, imo, is pretty good. You can draw anywhere on the screen, and once you get the hang of it you can work reasonably well, even with the CLI. Speed: its pretty good, it does slow down on occassion - this usually manifests itself in the 'stroke' graphic on screen drawing slowly, not in character recognition. i find that renicing it to -3 helps a
Oh... just a very minor one :(
:)
Yes, familiar can run on Zaurus. You'll have to hunt around for instructions though, or ask on the irc.freenode.net#gpe irc channel - i know that at least two of the more active developers have Zauruses (Zaurii?) (the C700).
Familiar runs its own kernel. I guess you'd have to keep your sharp kernel and run that. SD will (it seems) never be supported openly under linux, as the consortium controlling the specs will not release them.
Familiar pro-ipaq? Well, handhelds.org was setup by Compaq
Where did you get 'two' from?
ah.. probably cause i said "ie", that should have been "e.g.".
apologies.
Where did you get 'two' from? I gave 68k and x86 as examples, but binaries could be arbitrarily fat - another respondent gave examples of other arches. Additionally, i have a vague idea that you could 'strip' fat binaries of unneeded architecture code - not 100% sure on this.
Or what about the even cooler (but not as mature) GTK+ 2 based GPE? X based so when at home you can have your apps display to your desktop and make use of a real keyboard. Though the graffiti-like Xstroke app GPE uses is excellent and so you might not miss your desktop keyboard :).
As the author he is under /no/ obligation to provide source, he merely chooses to do so.
/not/ under GPL. Eg, some licence licence that allows use for free, and making of copies for ones /own/ use, but redistribution forbidden.
I think the answer is:
- Provide source under the GPL
- Provide certified binaries for a fee to cover the certification cost, and
He is the copyright holder i presume, so he can do what he wants with the licences.
Apple (well NeXT) solved that problem already. OpenStep (cant both to capitalise it correctly) ran on both 68k and x86 machines, and OpenStep software could be compiled to be 'fat', ie including both 68k and x86 machine code so it could be installed and executed on either architecture. Wasnt very popular, but disk space wasnt as cheap in those days as it is now.
Apple must still have that code lying around somewhere.
if some GPL code makes its way its something else... its is GPLed
This isnt true. If GPL code is incorporated into proprietary code, then it is a GPL licence violation (providing 'derived work' holds true). Licence violations mean you can seek redress, either by settling privately with the violator, or by getting a judge to rule in your favour. Redress could consist of damages and the violator excising the GPL code from his app, and/or even relicensing of the derived work under GPL.
But it is by no means automatic. What happens when GPL licence is violated is for the 2 parties to settle between themselves or, if they can not come to an amicable settlement, a judge to decide.
that's what we're discussing :). heap backed by mmap(): that is only true if the allocations are above a certain size according to the glibc info pages.
Yes, indeed, i think i referred to that in the last paragraph.
Note though that the threshold for glibc using mmap() is 128k, most allocations wont be anywhere near that large and will be allocated from heap. mmap() allocations have a performance overhead.
X maps the entire video ram. So if you have an 8MB card, then 8MB of X's supposed memory usage is actually mapped video ram. X can use the remaining 5 MB (eg 3MB used for display from your example) of video ram to store pixmaps, etc.. (google for XAA - X acceleration architecture iirc). If you have a 32MB card, then X will be at least 32MB in size, if you have a super duper 128MB card, X will be at least 128MB in size - just because of the VRAM mapping.