Wrong. You can _bundle_ any code with any other code. You can stick gnu tools on MSDN CDs that contain originally-BSD network stacks. Bundling's mere aggregation, and is unimportant licence-wise.
I, for one, thought for a moment that you were going to say that you, for one, welcome your huge shitstorm-over-a-minor-licensing-issue-resolving overlords.
The/. title is indeed a misrepresentation of the interview. The only reference to linux is where he says the equivalent of "on average, the linux kernel manages apportioning jobs to cores better than when we tried to manage it manually ourselves". If anything that's a complement for linux, not a criticism of it.
However, are you sure someone who thinks that one can use (C++) templates in C is an "expert".
Ingo et al. are fighting over which local maxima are best. What's that got to do with the price of eggs in China?
The customers always have that option, of course. However, for a chip vendor, it's enormously easier just to let the customers use a plain old gcc bundled in the BSP, because that way they then don't need to provide any support for it. Support is expensive. Instead, they can feed their system-specific patches back into the gcc mainline using a fiftieth of the staff, if that. I think we found and patched some issues with the vector floating point code generation, that's about the only thing I remember in a whole year working with the linux side of things.
I'm glad you posted the above, I can't claim to be an expert in the field, and your post was enlightenting. As I read the article, I repeatedly got the feeling that in response to PG's "Vista's DRM won't let you do X" I was being fed "Ah, but you can do X on Vista", with apparently no DRM being active. If Vista's DRM were to let you do X, then it seemed that the DRM was broken, as X was the thing that it was designed to prevent. Does that make sense?
What proportion of embedded devices come with the development tools on the device?
If I'm missing the point that 0.0001% of device manufacturers want to do something unusual, then I'm happy with that, I'll just stick with real world view. I know at $LARGE_CHIP_MFCTR gcc was utterly perfect for us and our customers.
And it can be so distributed with a gcc on the CD or in the tarball too. The license that gcc has has _no_ effect on the license that the rest of the package uses.
I get between 1.5x to 2.0x improvement between -O0 and -O2 (-O3 is rarely much faster)
E.g. here's the last thing I built, a simple AI for playing the board game/EinStein würfelt nicht!/. (it plays online at http://www.littlegolem.net/ )
That talk starts with what Rankin was doing last decade, and ends with some image processing that for example the Finnish VTT rejected as just a toy several years ago with a comment that they knew others too had already looked at it.
I wasn't aware that Microsoft Research was quite so far behind the cutting edge.
However, I can see a revival in Barnsley's fractal image compression coming on, now that CPU power has advanced.
I'm fairly sure this is just another submarine patent that simply covers what's been general, and so general it's not been worthy of publication, knowledge for ever and a day. I certainly know that the original (lab only) POWER cores did what the 1-line description claims.
I'm not sure I like the way this restatement is being made. For example: "The long and short of it is, if you can determine the value of the pointer, it's game over."
#include <stdio.h> #include <stdlib.h> int main() {
char buf[100];
char*p=malloc(10);
printf("The pointer's value is %p\n", p);
free(p);
fgets(buf,sizeof(buf),stdin);
return (buf[0]=='/') && (buf[1]=='.'); }
I'd like to see Thomas Ptacek exploit that - show me the "game over" - or to get on his knees, apologise for being a gobsite, and retract his absurd statement.
Nice figures. If they did use 3.5" diskettes, then they'd have to write 1000/1.44 per second or roughly 700/s. Assuming they could be written to instantly, they'd need to move through a single drive at 700*3.5"/s = 224km/h. Assuming you need to get them stationary to write to them, then they'd need a maximum speed of 448km/h to keep up the mean speed. Don't stand in their way...
Of course, the tower of floppies for each day would be 151km high...
""" If you allow the local user to install programs, then the local user is either; a) going to need write access to all the usual locations (either/usr/bin and/usr/lib, or/opt) which wouldn't solve the problem TFA is on about """
Nonsense, he's never going to *need* access to/usr/bin or/usr/lib. If he's in a sufficiently privileged *group*, then he can install it in/usr/local/*. If he's not, he's going to install it in ~.
People who aren't in a sufficiently privileged group, and at that for a reason, certainly should *not* be allowed to install drivers.
One thing that really pissed me off about Linux Journal was how every alternate month there's be an article about running some wanky application as a kernel module "for speed" or "for efficiency". For bleedin' idiocy, mate.
Then again, I shamelessly veer towards a micro-kernel preference.
Personally, I think Linux dropped below the 'cobbled together shit written by bodgers for idiots' about 3-5 years ago. I still run it on 6 out of my 8 machines though, as I've found nothing better.
Slashdot Mirror
Wrong. You can _bundle_ any code with any other code. You can stick gnu tools on MSDN CDs that contain originally-BSD network stacks. Bundling's mere aggregation, and is unimportant licence-wise.
I, for one, thought for a moment that you were going to say that you, for one, welcome your huge shitstorm-over-a-minor-licensing-issue-resolving overlords.
The /. title is indeed a misrepresentation of the interview. The only reference to linux is where he says the equivalent of "on average, the linux kernel manages apportioning jobs to cores better than when we tried to manage it manually ourselves". If anything that's a complement for linux, not a criticism of it.
However, are you sure someone who thinks that one can use (C++) templates in C is an "expert".
Ingo et al. are fighting over which local maxima are best. What's that got to do with the price of eggs in China?
Should he be considered a tech "expert" when the very thing he wants has been available in linux for years?
They don't _have to_, but if they didn't, they'd be liable for at least compensatory or perhaps punitive damages on a copyright infringement case.
"Using GPL software without complying with the GPL is a liability for any business. "
It's not even that - the Gnu GPL doesn't cover usage, only copying/distribution.
Your PP was of course just an inane fudster, probably a troll.
The customers always have that option, of course. However, for a chip vendor, it's enormously easier just to let the customers use a plain old gcc bundled in the BSP, because that way they then don't need to provide any support for it. Support is expensive. Instead, they can feed their system-specific patches back into the gcc mainline using a fiftieth of the staff, if that. I think we found and patched some issues with the vector floating point code generation, that's about the only thing I remember in a whole year working with the linux side of things.
I'm glad you posted the above, I can't claim to be an expert in the field, and your post was enlightenting. As I read the article, I repeatedly got the feeling that in response to PG's "Vista's DRM won't let you do X" I was being fed "Ah, but you can do X on Vista", with apparently no DRM being active. If Vista's DRM were to let you do X, then it seemed that the DRM was broken, as X was the thing that it was designed to prevent. Does that make sense?
What proportion of embedded devices come with the development tools on the device?
If I'm missing the point that 0.0001% of device manufacturers want to do something unusual, then I'm happy with that, I'll just stick with real world view. I know at $LARGE_CHIP_MFCTR gcc was utterly perfect for us and our customers.
And it can be so distributed with a gcc on the CD or in the tarball too. The license that gcc has has _no_ effect on the license that the rest of the package uses.
I get between 1.5x to 2.0x improvement between -O0 and -O2 (-O3 is rarely much faster)
/EinStein würfelt nicht!/.
./esbot.core2 -8 red 2 @@BMGK SXY@R@
./esbot.core2 -8 red 2 @@BMGK SXY@R@
E.g. here's the last thing I built, a simple AI for playing the board game
(it plays online at http://www.littlegolem.net/ )
-O0
phil@duospaz:~/projects/games/EinStein$ time
moveRedEval(@@BMGK,SXY@R@,8) XR = 1.80859
moveRedEval(@@BMGK,SXY@R@,8) XW = 0.83689
moveRedEval(@@BMGK,SXY@R@,8) XS = -0.35817
Selected=XS Score=-0.35817
user 0m18.777s
-O3
phil@duospaz:~/projects/games/EinStein$ time
moveRedEval(@@BMGK,SXY@R@,8) XR = 1.80859
moveRedEval(@@BMGK,SXY@R@,8) XW = 0.83689
moveRedEval(@@BMGK,SXY@R@,8) XS = -0.35817
Selected=XS Score=-0.35817
user 0m8.817s
That's entirely CPU bound (all fits in L1), and loads of 256-byte lookups, and some simple FPU evaluations.
Nose with an eye in it?
That talk starts with what Rankin was doing last decade, and ends with some image processing that for example the Finnish VTT rejected as just a toy several years ago with a comment that they knew others too had already looked at it.
I wasn't aware that Microsoft Research was quite so far behind the cutting edge.
However, I can see a revival in Barnsley's fractal image compression coming on, now that CPU power has advanced.
But it's not even that short. before killed IE a few years back, and was much shorter.
Patently Ludicrous Cases.
I'm fairly sure this is just another submarine patent that simply covers what's been general, and so general it's not been worthy of publication, knowledge for ever and a day. I certainly know that the original (lab only) POWER cores did what the 1-line description claims.
re. your journal entry - "MD5'ing incoming IP addresses"
Why?
I'm not sure I like the way this restatement is being made. For example:
"The long and short of it is, if you can determine the value of the pointer, it's game over."
#include <stdio.h>
#include <stdlib.h>
int main()
{
char buf[100];
char*p=malloc(10);
printf("The pointer's value is %p\n", p);
free(p);
fgets(buf,sizeof(buf),stdin);
return (buf[0]=='/') && (buf[1]=='.');
}
I'd like to see Thomas Ptacek exploit that - show me the "game over" - or to get on his knees, apologise for being a gobsite, and retract his absurd statement.
And don't forget, 4.01% of people on the internet live in Latvia!
Nice figures. If they did use 3.5" diskettes, then they'd have to write 1000/1.44 per second or roughly 700/s. Assuming they could be written to instantly, they'd need to move through a single drive at 700*3.5"/s = 224km/h. Assuming you need to get them stationary to write to them, then they'd need a maximum speed of 448km/h to keep up the mean speed. Don't stand in their way...
Of course, the tower of floppies for each day would be 151km high...
No, I don't know what that is in football fields.
AJAX? xmlHttpRequest?
Oh, please. It's much easier than that. These hacks have been possible using much more lo-tech techniques since scripting began.
2nd paragraph - you want stuff in AJAX, but to not use JavaScript?
Does not compute.
""" /usr/bin and /usr/lib, or /opt) which wouldn't solve the problem TFA is on about
/usr/bin or /usr/lib. If he's in a sufficiently privileged *group*, then he can install it in /usr/local/*. If he's not, he's going to install it in ~.
If you allow the local user to install programs, then the local user is either;
a) going to need write access to all the usual locations (either
"""
Nonsense, he's never going to *need* access to
People who aren't in a sufficiently privileged group, and at that for a reason, certainly should *not* be allowed to install drivers.
""" :-)
Once more boys and girls, say it with me now, SUID IS EVIL!
Nothing but the programs that absolutely have to should be run as root.
"""
If nothing but the programs that absolutely have to run as root, then SUID is _perfect_.
It's not the tool that's flawed, it's the uses of the tool.
SUID bits don't kill people, sloppy programmers who rely on SUID bits kill people.
... dropped below the '... shit ...' *horizon* ...
Amen!
One thing that really pissed me off about Linux Journal was how every alternate month there's be an article about running some wanky application as a kernel module "for speed" or "for efficiency". For bleedin' idiocy, mate.
Then again, I shamelessly veer towards a micro-kernel preference.
Personally, I think Linux dropped below the 'cobbled together shit written by bodgers for idiots' about 3-5 years ago. I still run it on 6 out of my 8 machines though, as I've found nothing better.