indeed, i'm well aware of that, but you're missing something - X clients can ask the X server to create 'objects' usually pixmaps which persist for the lifetime of that X client connection. There are bad apps out there that forget to free objects, and just keep creating new ones, causing the X RAM usage to balloon. The app needs fixing.
Shutting down the X client will cause the X server to free any objects it had. However, you probably will not see your RAM usage go down - as glibc/never/ shrinks the heap (difficult thing to do). The solution perhaps might be for the X server to use private mapped memory for some allocations.
Note that because glibc never shrinks the heap that RAM usage is a/maximum/. If you see X with 80MB of data, it just means that at some point in the lifetime of the process glibc had to allocate 80MB of heap to fulfill requirements. A lot of that heap though might well be marked "free" (ie allocated by OS, but marked free by glibc and available for use by malloc()) - so future malloc requests by X may very well be allocated from the existing heap without any need for glibc to increase amount of RAM used.
This is a general problem with glibc, or rather heap based memory management. You could add heap defragmentation and shrinking to glibc, but that might well cause long pauses in applications while glibc defrags - which application would have little control over. Heaps will become fragmented, they are hard to shrink without paying a cost. (though glibc will switch to private mappings if requests are beyond a certain size, and private mappings are easily freed once the app calls free()).
yes indeed it is. if you look at the figures i quoted they do not add up to the full 5.9MB figure i quoted for the size of the X server - the difference is mapped memory, the framebuffer being one of the mappings. However, the framebuffer on the ipaq is tiny - 320x240x16bpp -> 150KB, so its fairly insignificant.
First of X is not that bloated - have a look at TinyX (part of the XFree tree), its 868 kilobytes in size and is currently using about 5.9MB of RAM on my Ipaq (868KB for the exe, 2MB for libraries and just 2.6MB for data - and thats with a few apps open too).
People who say X is bloated are either ignorant or liers.
Also, X provides things which plain framebuffers do not which must/still/ be done somewhere if one wishes to actually have more than one app displaying to that framebuffer, ie arbitration. If you look at toolkits designed for plain fb's, eg QtEmbedded, they have a good bit of code in them to allow for arbitration between different apps for access to the framebuffer (and hey, now you need scheduling code too!). Iirc, there was an interview with one of the guys who was involved early on with the Berlin project, and he said that by time they had all the things needed to allow apps to work together on displays they werent far off the size of an X server anyway.
Also, often when people blame X for bloat they're blaming the wrong thing. They see X taking up 80MB on their desktop and go "oh bloated" - but in all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!
The post is 100% correct, this/. article demonstrates precisely the downsides of closed hardware (implied from closed source drivers), ie the open source community cant hack on them and do new things with them.
This is bull. Lots of graphics vendors used to provide open specs to the open source community. I had a Matrox MGA2064W Mil2 with perfect open drivers and high quality 2D 1600x1280@24bpp a/long/ time ago. It took lots of lobbying and pressure from users/developers, but eventually those companies that wouldnt provide specs usually would open up.
Then the rot started, Matrox (who up till then always were very good about open specs) stopped providing full specs. At first, they restricted information to the Warp engine included with the G200 (needed for 3D), and provided binary microcode. This was sort of ok, as it was code that could only ever run on the card ASIC. Then they provided a binary only library for some of the dual-head and other features rather than releasing specs. NVidia stopped providing specs (which they had previously under pressure and NDA) and released binary only drivers.
The worst part is that the new-wave of linux users accepted this. Bought the cards and downloaded the drivers and used them without any complaint - glad even that the vendors were releasing binary only drivers, but completely ignorant and, worse, undoing the many years of earlier hard lobbying by open source developers and users to get manufacturers to provide specs.
I think you're wrong about Parhelia btw, the open Matrox mga driver works with it in 2D iirc. The open NVidia driver also works with most NV cards in 2D. But for how long will we continue to have open graphics drivers, now that the new wave of linux users have shown the manufacturers they are more than happy with closed drivers.
Oh, and if you're not using x86 - you're screwed..
well, he.net have a lot of address space, and only small parts are blacklisted. so... most he.net users will be ok. but some people might be unlucky and end up with a spammer 'next door' (in address space terms) and be caught in the blacklists.
Hurricane Electric are possibly not the best of choices to use. They are, by repute, a big spam-friendly hosting outfit and appear to be widely blacklisted, SPEWS blacklist (NB: thats just one spews record that lists HE.net space) quite a bit of their space, the SBL has a few listings for them, they're also listed by blackhole.us.
So, when considering Hurricane.net bear in mind you may well have problems with email being rejected and even complete blackholing of connectivity to/from some sites.
They care about sending spam, so they cant just shovel everything down the connection without getting replies. Most MTAs do/not/ support SMTP PIPELINE which would support it, and the ones that do (eg sendmail) generally are no longer configured to allow 3rd party relay. So they have to wait, or most of their spam probably wont be sent. (be great if they did what you say they do, we wouldnt get anywhere near the levels of spam currently..).
They could indeed make lots of connections in parallel, but they cant make a million in parallel. they could at most have ~65k in parallel with IPv4, and even that would be asking too much of an OS (work out the amount of memory 65k TCP connections would take just for OS to maintain state, now add the memory requirements for the SMTP spamming application). Probably # of connections in parallel is 100 at most (probably more like order of 10 or so).
Well, we dont know if that was 'later', afaict from the emails they had this system by at least 1957. As for "knowing where on the ground this point is", well i think that was precisely my point about "the hard work happens on the ground" - its all in the planning, the pilots would have spent hours surveying maps and photos as part of the planning process.
I'm not denying the airmanship needed, but even this is the result of planning. Training is part of the plan.:)
And actually, its not much different today with JDAMs and other smart munitions. Again, there's tonnes of planning that goes into this - on the crews part alone, even more planning behind the scenes. Also, these bombs generally are/not/ powered, you/do/ still have be accurate with your release point (though these days your planning would determine the release point as a coordinate obtained via GPS, not as a vector,time tuple from an IP).
Anyway, i think you do not appreciate to any significant degree how big a factor planning is in aviation, be it military or civil. Even the simplest aspects require planning, eg just to take-off you generally have to spend at least 5 minutes working out factors such as at what IAS V1, Vr and V2 will occur (which is dependent on weight of airplane, current mercury level (pressure)). And you'll spend at least another 10 minutes on pre-flight checks. Just for takeoff:)
Bombing hasnt gotten "easy", its just the bombs and tactics have changed. Training, planning and ground work is still the biggest part of the job (which is a general truth in aviation).
The IP is the point at which they pressed the button (pickle) to start the LABS running, the LABS had a timer and would indicate when to begin pull up, release was done by LABS. The timer was set in planning, where pilot would have picked an IP and worked out the needed vector and time from IP to pull-up. So i'd actually say the/planning/ is the critical bit. (and, strangely, this applies to nearly everything in aviation - a lot of the hard work happens on the ground.).
complex and inaccurate maneuver? Its a half-cuban eight, quite standard and most pilots who've done any kind of introductory aerobatics lesson will probably have done them, combat pilots in dive bombers would have done a lot of them already.:)
If you read the emails it seems they, later missions at least, had some kind of mechanical computer that would release the weapon when the required angle and G was reached.
The spammers already are using "business" links, several even. There is at least one who has 3 T1 links to their house, occassionally getting new ones in as they get kicked from ISPs.
It takes a reasonable amount of bandwidth to send a million+ emails in a reasonable amount of time. Eg, 4KiB message * 1M = 3906MiB, which would take 43 minutes to send across a T1 in itself. Sending via SMTP will require several round trips to the destination SMTP server, per message. So count on it taking/much/ longer than that, with a T1. Probably a day.
Its not NFSs job to handle the mechanics of authentication. The NFSv4 etc code is in the kernel, but something else needs to handle the authentication and that shouldnt be in kernel (in-kernel kerberos'd be a bit silly). So there's needs to be some daemon that the kernel can communicate with and which can handle all the neccessary security stuff and pass the result back to kernel, as far as i know that work isnt fully complete.
ok... you're completely wrong about NFS and security.
It does not rely on hostnames for security, it does not rely on trusting the client to authenticate the user. NFS in fact relies solely on/RPC/ to provide the security. The mechanics of authentication or securing the RPC transport just are plain not in the remit of NFS.
Sun RPC in fact can be quite secure. There are various security mechanisms it can employ, and the problems you're just describing are all with one specific mechanism: auth_unix. It just happens to be the most commonly used one, and the only one supported on linux. However, if you use Solaris or OpenBSD there are other mechanisms available, eg auth_dh (public key based i think), auth_kerb (kerberosv4 - was secure, but flaws are known) or auth_gss (Most recent mechanism: Generic Security API / Kerberos V5 typically - which can be quite secure.).
The problem is that auth_unix is the easy option, and the only one that is guaranteed to be implemented by RPC. However, thankfully, with NFSv4 this will change as it makes support for AUTH_GSS and/mandatory/, which linux 2.5 has support for (not sure though whether all the userspace support is there yet). So 2.6 will hopefully at last support high-strength secure authentication for RPC (and hence for NFS v2,3 and 4) via the AUTH_GSS rpc_sec auth mechanism.
Its hilarious to hear car people going on about power to weight ratio and having 400HP at the back wheel and 0-60 in 5s.
My little 250cc motorbike still smokes nearly every car out there. (and for the very very few cars it doesnt, i'll just point to any of the 1L Yamaha or Suziki sports bikes available for less than 15k at any local motorbike shop).
People who think cars are fast are deluded.
Re:Use MAC address filtering and Limited IP leases
on
How Stable is WEP?
·
· Score: 2, Interesting
'ip maddr' is for tweaking multicast addresses. you meant 'ip link set address ' i think:)
We get CNN, BBC, Sky News (murdoch owned) and for an hour at night CBS (shown on sky strangely). BBC 24 is imo the best, they try very hard to be impartial and objective.
One thing i do not understand though, why is it that all the US stations seem only to be able to get really lossy MPEG type video from their in-situ reporters, while the european based reporters can get perfect TV quality video live from baghdad, carriers, etc.. and even from their 'embedded' reporters?
Are the american stations really 10 years behind in infrastructure and technology (dont believe that), or is this some kind of ploy to make the war seem more 'distant' and less real to the US public? Odd anyway.
One design? You seem to have a clue deficiency. Btw, i failed to mention that at the same time a certain Mr. Daimler also invented the 'car'. (also a german).
the auto was DEVELOPED in the USA (Ford Motors) first mass production.
Ok, and/when/ did Mr. Ford develop the model T? By the time he came along with that there were/lots/ of other car designs. He did invent the assembly line apparently. But thats not a car.
we can say PERSONAL computers were developed in the USA
Indeed, You see, i'm not denying the USA has invented many things, i actually explicitly acknowledged it did. However, i am trying to help you with your USA-invented-Everything delusion. Again, would it have been possible for the USA to have developed personal computers if it were not for all that had gone before?/mankind/ invented these things, and ultimately it matters not which inventions were invented where, we all ultimately benefit. (hopefully).
Encryption has been around for thousands of years.. as has mathematics.
At this stage I would recommend you consult a few history books. Particularly, pay attention to the "dark ages", where most of europe "lost" nearly all the advanced knowledge built up by earlier civilisations (ie by the greeks). During that time, the/Arabs/ - in particular the arabs in what is now generally Iraq - maintained and advanced the state of the art in mathematics and other fields.
Also, i suggest you look up the difference between cryptanalysis and encryption.
America is not an "uneducated" country
Indeed it isnt, though you're one of the dimmer lightbulbs it seems. Course, Arabs are not "uneducated" either.
Additionally, the $ we are spending to FREE IRAQ is money well spent (afterall, we STILL have 80% of the worlds wealth).
You have a disproportionate amount of the world's wealth, but i doubt you have 80% - not economically feasible considering Europe isnt terribly poor either. Care to back up that figure? Even if so, all that wealth and you still cant buy a clue...
Slashdot Mirror
indeed, i'm well aware of that, but you're missing something - X clients can ask the X server to create 'objects' usually pixmaps which persist for the lifetime of that X client connection. There are bad apps out there that forget to free objects, and just keep creating new ones, causing the X RAM usage to balloon. The app needs fixing.
/never/ shrinks the heap (difficult thing to do). The solution perhaps might be for the X server to use private mapped memory for some allocations.
/maximum/. If you see X with 80MB of data, it just means that at some point in the lifetime of the process glibc had to allocate 80MB of heap to fulfill requirements. A lot of that heap though might well be marked "free" (ie allocated by OS, but marked free by glibc and available for use by malloc()) - so future malloc requests by X may very well be allocated from the existing heap without any need for glibc to increase amount of RAM used.
Shutting down the X client will cause the X server to free any objects it had. However, you probably will not see your RAM usage go down - as glibc
Note that because glibc never shrinks the heap that RAM usage is a
This is a general problem with glibc, or rather heap based memory management. You could add heap defragmentation and shrinking to glibc, but that might well cause long pauses in applications while glibc defrags - which application would have little control over. Heaps will become fragmented, they are hard to shrink without paying a cost. (though glibc will switch to private mappings if requests are beyond a certain size, and private mappings are easily freed once the app calls free()).
yes indeed it is. if you look at the figures i quoted they do not add up to the full 5.9MB figure i quoted for the size of the X server - the difference is mapped memory, the framebuffer being one of the mappings. However, the framebuffer on the ipaq is tiny - 320x240x16bpp -> 150KB, so its fairly insignificant.
First of X is not that bloated - have a look at TinyX (part of the XFree tree), its 868 kilobytes in size and is currently using about 5.9MB of RAM on my Ipaq (868KB for the exe, 2MB for libraries and just 2.6MB for data - and thats with a few apps open too).
/still/ be done somewhere if one wishes to actually have more than one app displaying to that framebuffer, ie arbitration. If you look at toolkits designed for plain fb's, eg QtEmbedded, they have a good bit of code in them to allow for arbitration between different apps for access to the framebuffer (and hey, now you need scheduling code too!). Iirc, there was an interview with one of the guys who was involved early on with the Berlin project, and he said that by time they had all the things needed to allow apps to work together on displays they werent far off the size of an X server anyway.
People who say X is bloated are either ignorant or liers.
Also, X provides things which plain framebuffers do not which must
Also, often when people blame X for bloat they're blaming the wrong thing. They see X taking up 80MB on their desktop and go "oh bloated" - but in all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!
Why is the parent modded as flamebait?
/. article demonstrates precisely the downsides of closed hardware (implied from closed source drivers), ie the open source community cant hack on them and do new things with them.
The post is 100% correct, this
This is bull. Lots of graphics vendors used to provide open specs to the open source community. I had a Matrox MGA2064W Mil2 with perfect open drivers and high quality 2D 1600x1280@24bpp a /long/ time ago. It took lots of lobbying and pressure from users/developers, but eventually those companies that wouldnt provide specs usually would open up.
Then the rot started, Matrox (who up till then always were very good about open specs) stopped providing full specs. At first, they restricted information to the Warp engine included with the G200 (needed for 3D), and provided binary microcode. This was sort of ok, as it was code that could only ever run on the card ASIC. Then they provided a binary only library for some of the dual-head and other features rather than releasing specs. NVidia stopped providing specs (which they had previously under pressure and NDA) and released binary only drivers.
The worst part is that the new-wave of linux users accepted this. Bought the cards and downloaded the drivers and used them without any complaint - glad even that the vendors were releasing binary only drivers, but completely ignorant and, worse, undoing the many years of earlier hard lobbying by open source developers and users to get manufacturers to provide specs.
I think you're wrong about Parhelia btw, the open Matrox mga driver works with it in 2D iirc. The open NVidia driver also works with most NV cards in 2D. But for how long will we continue to have open graphics drivers, now that the new wave of linux users have shown the manufacturers they are more than happy with closed drivers.
Oh, and if you're not using x86 - you're screwed..
well, he.net have a lot of address space, and only small parts are blacklisted. so... most he.net users will be ok. but some people might be unlucky and end up with a spammer 'next door' (in address space terms) and be caught in the blacklists.
Hurricane Electric are possibly not the best of choices to use. They are, by repute, a big spam-friendly hosting outfit and appear to be widely blacklisted, SPEWS blacklist (NB: thats just one spews record that lists HE.net space) quite a bit of their space, the SBL has a few listings for them, they're also listed by blackhole.us.
So, when considering Hurricane.net bear in mind you may well have problems with email being rejected and even complete blackholing of connectivity to/from some sites.
You're wrong though, the driver is /completely/ closed. The only part that is open is the glue code needed to interface their driver to the kernel.
Not really, you paid for the hardware.
Err.. how can NVidia lead in free software support when their driver is completely closed and proprietary?
They care about sending spam, so they cant just shovel everything down the connection without getting replies. Most MTAs do /not/ support SMTP PIPELINE which would support it, and the ones that do (eg sendmail) generally are no longer configured to allow 3rd party relay. So they have to wait, or most of their spam probably wont be sent. (be great if they did what you say they do, we wouldnt get anywhere near the levels of spam currently..).
They could indeed make lots of connections in parallel, but they cant make a million in parallel. they could at most have ~65k in parallel with IPv4, and even that would be asking too much of an OS (work out the amount of memory 65k TCP connections would take just for OS to maintain state, now add the memory requirements for the SMTP spamming application). Probably # of connections in parallel is 100 at most (probably more like order of 10 or so).
Well, we dont know if that was 'later', afaict from the emails they had this system by at least 1957. As for "knowing where on the ground this point is", well i think that was precisely my point about "the hard work happens on the ground" - its all in the planning, the pilots would have spent hours surveying maps and photos as part of the planning process.
:)
/not/ powered, you /do/ still have be accurate with your release point (though these days your planning would determine the release point as a coordinate obtained via GPS, not as a vector,time tuple from an IP).
:)
I'm not denying the airmanship needed, but even this is the result of planning. Training is part of the plan.
And actually, its not much different today with JDAMs and other smart munitions. Again, there's tonnes of planning that goes into this - on the crews part alone, even more planning behind the scenes. Also, these bombs generally are
Anyway, i think you do not appreciate to any significant degree how big a factor planning is in aviation, be it military or civil. Even the simplest aspects require planning, eg just to take-off you generally have to spend at least 5 minutes working out factors such as at what IAS V1, Vr and V2 will occur (which is dependent on weight of airplane, current mercury level (pressure)). And you'll spend at least another 10 minutes on pre-flight checks. Just for takeoff
Bombing hasnt gotten "easy", its just the bombs and tactics have changed. Training, planning and ground work is still the biggest part of the job (which is a general truth in aviation).
as i understood from the emails:
/planning/ is the critical bit. (and, strangely, this applies to nearly everything in aviation - a lot of the hard work happens on the ground.).
The IP is the point at which they pressed the button (pickle) to start the LABS running, the LABS had a timer and would indicate when to begin pull up, release was done by LABS. The timer was set in planning, where pilot would have picked an IP and worked out the needed vector and time from IP to pull-up. So i'd actually say the
Plus of course, they ran WinXP on it, so they tested it in 32bit mode. Its concievable it might be faster still in long mode.
complex and inaccurate maneuver? Its a half-cuban eight, quite standard and most pilots who've done any kind of introductory aerobatics lesson will probably have done them, combat pilots in dive bombers would have done a lot of them already. :)
If you read the emails it seems they, later missions at least, had some kind of mechanical computer that would release the weapon when the required angle and G was reached.
The spammers already are using "business" links, several even. There is at least one who has 3 T1 links to their house, occassionally getting new ones in as they get kicked from ISPs.
/much/ longer than that, with a T1. Probably a day.
It takes a reasonable amount of bandwidth to send a million+ emails in a reasonable amount of time. Eg, 4KiB message * 1M = 3906MiB, which would take 43 minutes to send across a T1 in itself. Sending via SMTP will require several round trips to the destination SMTP server, per message. So count on it taking
your car is not a part of your wheel.
Its not NFSs job to handle the mechanics of authentication. The NFSv4 etc code is in the kernel, but something else needs to handle the authentication and that shouldnt be in kernel (in-kernel kerberos'd be a bit silly). So there's needs to be some daemon that the kernel can communicate with and which can handle all the neccessary security stuff and pass the result back to kernel, as far as i know that work isnt fully complete.
ok... you're completely wrong about NFS and security.
/RPC/ to provide the security. The mechanics of authentication or securing the RPC transport just are plain not in the remit of NFS.
/mandatory/, which linux 2.5 has support for (not sure though whether all the userspace support is there yet). So 2.6 will hopefully at last support high-strength secure authentication for RPC (and hence for NFS v2,3 and 4) via the AUTH_GSS rpc_sec auth mechanism.
a -nfsd-auth/paper/node2.html
/not/ its fault.
It does not rely on hostnames for security, it does not rely on trusting the client to authenticate the user. NFS in fact relies solely on
Sun RPC in fact can be quite secure. There are various security mechanisms it can employ, and the problems you're just describing are all with one specific mechanism: auth_unix. It just happens to be the most commonly used one, and the only one supported on linux. However, if you use Solaris or OpenBSD there are other mechanisms available, eg auth_dh (public key based i think), auth_kerb (kerberosv4 - was secure, but flaws are known) or auth_gss (Most recent mechanism: Generic Security API / Kerberos V5 typically - which can be quite secure.).
The problem is that auth_unix is the easy option, and the only one that is guaranteed to be implemented by RPC. However, thankfully, with NFSv4 this will change as it makes support for AUTH_GSS and
See:
http://www.cse.unsw.edu.au/~neilb/conf/lca2002/lc
and the rpc and rpc_secure (if your system supports it) man pages for more info on RPC security.
Anyway, stop blaming NFS for things that are
passenger? what's that? :)
Its hilarious to hear car people going on about power to weight ratio and having 400HP at the back wheel and 0-60 in 5s.
My little 250cc motorbike still smokes nearly every car out there. (and for the very very few cars it doesnt, i'll just point to any of the 1L Yamaha or Suziki sports bikes available for less than 15k at any local motorbike shop).
People who think cars are fast are deluded.
'ip maddr' is for tweaking multicast addresses. you meant 'ip link set address ' i think :)
We get CNN, BBC, Sky News (murdoch owned) and for an hour at night CBS (shown on sky strangely). BBC 24 is imo the best, they try very hard to be impartial and objective.
One thing i do not understand though, why is it that all the US stations seem only to be able to get really lossy MPEG type video from their in-situ reporters, while the european based reporters can get perfect TV quality video live from baghdad, carriers, etc.. and even from their 'embedded' reporters?
Are the american stations really 10 years behind in infrastructure and technology (dont believe that), or is this some kind of ploy to make the war seem more 'distant' and less real to the US public? Odd anyway.
One design? You seem to have a clue deficiency. Btw, i failed to mention that at the same time a certain Mr. Daimler also invented the 'car'. (also a german).
/when/ did Mr. Ford develop the model T? By the time he came along with that there were /lots/ of other car designs. He did invent the assembly line apparently. But thats not a car.
/mankind/ invented these things, and ultimately it matters not which inventions were invented where, we all ultimately benefit. (hopefully).
/Arabs/ - in particular the arabs in what is now generally Iraq - maintained and advanced the state of the art in mathematics and other fields.
the auto was DEVELOPED in the USA (Ford Motors) first mass production.
Ok, and
we can say PERSONAL computers were developed in the USA
Indeed, You see, i'm not denying the USA has invented many things, i actually explicitly acknowledged it did. However, i am trying to help you with your USA-invented-Everything delusion. Again, would it have been possible for the USA to have developed personal computers if it were not for all that had gone before?
Encryption has been around for thousands of years.. as has mathematics.
At this stage I would recommend you consult a few history books. Particularly, pay attention to the "dark ages", where most of europe "lost" nearly all the advanced knowledge built up by earlier civilisations (ie by the greeks). During that time, the
Also, i suggest you look up the difference between cryptanalysis and encryption.
America is not an "uneducated" country
Indeed it isnt, though you're one of the dimmer lightbulbs it seems. Course, Arabs are not "uneducated" either.
Additionally, the $ we are spending to FREE IRAQ is money well spent (afterall, we STILL have 80% of the worlds wealth).
You have a disproportionate amount of the world's wealth, but i doubt you have 80% - not economically feasible considering Europe isnt terribly poor either. Care to back up that figure? Even if so, all that wealth and you still cant buy a clue...