I mean, the MTA supercomputer which pioneered the entire SMT concept, was able to run 128 threads per cpu.
It is an older concept (20 years or maybe 30!), look up barrel processors sometime. I'm pretty sure the MTA executed one thread per CPU per cycle with no penality for switching between threads on diffrent cycles. It would switch threads any time a load was issued, any time the store buffer was full and a store was issued, and after X cycles. The resources you need for an MTA thread would be more or less an extra set of registers.
Anyway, is there any specific reason why IBM didn't put more than 2, say 8 or 16 threads per cpu on the power5?
SMT (at least as the Alpha EV8, and IBM Power5 do it, I'm not sure what Intel's HT is exactly, but I think it is the same) executes more then one thread every cycle. So you need not only an extra register set per thread you need to make the "dispatch this to an ALU" logic more complex, and I think that is non-linear. I don't know why two seems to be the magic number and not 4 or something, but the higher cost per thread in SMT shows why you don't just add a ton of threads.
I don't agree with you. This will make patching and updating the system far easier than before and it will reduce disk space requirements, which should always be a goal no matter how big hard drives get. My only concern would be in regards to a performnace hit.
I agree that patching will be easier, unless you patch a library bug that shows up in the new/recovery tools. I'm not so sure about making the overall disk space requirement smaller, if the/recover tools are even close to the full set of stuff that is now dynamically linked the total disk use is higher. The only saving grace there is you might not put/recover on the same disk partition as/. Not really a win.
So patching is in some cases better, total disk space usage is probably up, and performance is probably down a little bit (unmemorable unless you are looking for it). Not in my opinion a good change, but not bad enough to send me scurrying off to AnotherBSD, not by a long shot. In the grand scheme of things it is a tiny change.
The last paper I read on dynamic linking showed about a 2% penalty on RISC CPUs and a bit over 10% on CISCs (losing one of 16+ registers to hold a libs base pointer hurts less then losing one of "about 4 to 8" registers!). That was a long time ago though, around when Sun added them to SunOS, maybe the early 90s or late 80s. Very short running programs (ls and echo) were hurt a lot more. Oddly enough some very small programs (like cat and echo) were larger as dynamic linked code (more disk space used to record the static code to invoke the dynamic linker, and to hold the symbols to link).
It mattered to me more then too. I didn't have SunOS source so any lib bug I wanted to fix, or lib call I wanted to improve wasn't gonna happen for the static programs.
The trick is this new memory is write once, read many. So is there really a benefit to consumers or is this just a way to improve the profitability of the corporations[...]
Um, so are CD-R and DVD-R, but I don't see people complaining. As long as this thing has a low enough price it will replace those things just fine. That is it's most likely target market.
If it is cheap enough it could replace FLASH since FLASH has a limited number of erase cycles, so if 100000 times as much of this new memory cost less then FLASH that could only be written 100000 times it is a win... but that seems less likely.
With the other forms of solid state memory you have the benefit of write many, read many.
PROMs are solid state and "write once", EPROMS are solid state and while they are "write many" they need exposure to strong UV light so they tend to be "write once" in field equiptment. MROM is "write when fab'ed". PROM, EPROM (and EEPROM) have all more or less vanished as FLASH ROM became dominant because it was re-writable. MROM is still seen from time to time because it is dirt cheap in quantity.
10.2.8 was a notable anomaly in Apple update history. It unintentionally disabled Ethernet on some-not-all 3+ year old dual processor G4s, not a good thing and inexcusable, but not exactly widespread or havoc-wreaking either.
Er, and don't forget the other notable anomaly, one of the first iTunes updates forgot to handle spaces in file names (which are common on Macs) and could delete vast swaths of your stuff.
Other then those two I can't think of any bad upgrade experiences from Apple.
I've written programs that do trillions of operations and then run some numbers against them. In case of some weird hardware failure or human error the code is run on three machines at the same time (the program takes a few days to run). What you are saying is that along the way the x86 hardware will incorrectly compute data and return bunk results? As a programmer (though not a low-level type), I'd expect that this would have come to my attention by now. Can you provide some examples or documentation? Of course there was the now famous Pentium flaw, but otherwise, what is defect rate on x86 operations?
Think about hardware at the gate level, your adders are a bunch of flip flops. A whole lot of them. And very very tiny ones holding very little charge. A cosmic ray striking one can change it's value (I think only form one to zero, or zero to one depending on the process and wether charged or discharged represents a zero or a one). If the cosmic ray hits one of the flip flops that is being used to produce a value about to go to a live register and then off to memory it can change the results from what your code should calulate to something with a one bit error. Maybe a low bit and the result is off by pennies, maybe a high bit and the result is so amazingly off that an assert later in the code catches it, or just a human eyeballing the results would. Worse yet something in the mid rage that nobody notices until far too late (if ever).
This is the same thing that ECC in memory helps prevent (ECC can't protect against multiple bit failures, but while a box with multiple gigs of memory will likely get a soft memory error in your lifetime, multiple bit errors before the scrubber finds them is really really really amazingly unlikely).
It is a force that gets worse as we go to lower voltage systems (less of a hit needed to flip values), and as we get greater densities (more likelyhood of the cosmic ray hitting something other then dead space -- at least I think so on this one).
It can be combated by having ECC on register and cache values (or even parity as long as the bits are "big enough" that a single cosmic ray hit won't flip multiple bits!), but having similar checks on ALU operations, or just sending the values through identical ALUs that are on diffrent parts of the chip and compairing them after (rerun any cycle where the results differ, either totally in hardware or trapping to the OS to let it restart the instruction after logging the hit). Not rocket science, but it makes for a more costly CPU, and it makes for a slightly slower CPU (in fact much slower when you factor in the extra transistors used for correctness checks that a "normal" CPU would use for cache or some other performance boosting geegaw).
As for documentation I don't recall where I saw studies done, probbaly in one of the ACM or IEEE procedings, but if you don't have access to them comp.risks might turn something up (and a lot of other stuff that might be more worth worring about:-)
Note also that you are talking about the specific *implementation* deficits in several window managers. Those may point to unclear protocol specifications or to bad code. Frankly, I suspect the latter. Code can be very broken if it makes assumptions about its input parameters without checking them first.
This specific problem was that most window managers (all except UWM as far as I know) want to display decorations on the managed windows (resize, iconify, title bars, and so on). To do so they reparent the managed (application) windows so that they are contained inside windows the window manager owns (and therefore windows the WM can draw in without bothering the applications they manage).
When a window manager written prior to shaped window extentions (or that just doesn't care) reparents a shaped window you get a non-rectangular child window inside a rectangular window that the window manager owns. That rectangular window will pretty much make the child's shaped window look rectangular.
There isn't much you can do about that if you want to allow pre-extention applications (like window managers) to work with post-extention applications (the managed apps). There isn't any "checking of paramaters" the window managers could have done in 1990 that would prepair them for the 1991 addition of shaped windows. Nor is there much of anything that an X window manager can do in 2003 to make it work and play well with stuff using extentions that might be released in 2004 or 2037.
Agreed, but the worst outcome is that you can't use the new feature until your favourite applications work out-of-the-box with the feature enabled. The biggest problem will be finding the #define to (un)comment or set:).
Well if you really like a window manager that is no longer being maintianed then there may never be a #define! Of corse historically the extentions don't not work, they are just visually a little iffy (windows that should be round aren't), and in the future that is likely to still be the case (transparent windows with very solid title bars).
Smaller projects maintained by "less talented" people are probably safe, actually, for the simple reason that the crackers probably haven't heard of them either.:p
Sure, but what aobut something like libmng which doesn't have that much in the way of people looking at it, yet is stuck into Mozilla (some versions at any rate) and fed datastreams directly from the web? And how many people pour over tcsh's sources for security holes?
Seriously - can you at least handshake with another modem ? No compression, no EC - just a basic
CONNECT 300/NONE
Last I attempted it 18 years ago or so yes, I could (it was just "CONNECT", not "CONNECT 300/NONE", either the extended status code hadn't been invented, or I didn't know how to turn it on at the time).
I don't think I have the lung capacity to whistle long enough for a modern modem to ratchet back to 300 baud though!
I think I use to be able to send the letter A as well, well a buch of @ signes and stuff, but I use to be able to make it do more a fewer A's for some reason. Then again it's a bit over half my lifetime ago, so I don't remember that part clearly....
However, they don't have to. Instead, they can cut the GPLed code out of their product.
They can, and it will prevent further damages from pileing up, but how does stopping steeling eliminate any past penalties? If the RIAA storms your house can you just say "sorry, the next version of my music collection will no longer include stolen music, please move on"? (ok, maybe I should have used a less hated group for an example, but...)
They will stop shipping their current version of the software. The next version will either not have iTerm-like functionality, or they will get similar code from some other source.
So they rip off free software, find out a feature is desired, and then write the code themselves. Very inexpensave prototypeing:-)
They don't have to release their code to anyone. They may have to pay damages if they get sued, due to the copyright violation that they have already done.
Rats, you beat me to it:-) I susspect that since they aren't SCOlike slime, but a company that looks like it thought it was doing the right thing by publising their iterm changes and such that the iterm authors will probbably let them get away with just no longer offending and not actually worry about "past damage".
I agree. I think that these music download services are a step in the right direction. My big problem is that I'm not purchasing a tangible good when I download music. What if my hard drive crashes? What if the company goes out of business (or abandons that division). What if my encription "key" stops working? Will I be able to use it on all my devices in some way or another? There's just too many unknowns in that purchase for me to feel comfortable, especially at a dollar a song.
Well with iTMS you are allowed to burn the music to a normal audio CD, so if you want a physical tangable non-revokable form for your downloaded music, have at it.
Of corse if you ever have to re-convert it to AAC or something it will sound worse then the original, but them's the breaks. (oh, and you have to factor in the $0.05/disc for the CD-R)
For me I'll buy it from iTMS if I didn't want the rest of the alblum, or if it is a lot cheaper, or if I'm too impatent to go to the store...er...wait...that doesn't leave a whole lotta times I'll buy a physical CD now!
Whatever journalist wrote this should be sent home without lunch!
What the hell do you mean unclear?
Here, let's take a stab; Pepsi Co. announces 1 million song giveaway via redeemable codes on their three main product bottle caps. 1 in 3 caps will have a code valued at $0.99. Hundreds of thousands of iTunes Music Store users are now poised and ready to only drink and purchase Pepsi, Diet Pepsi and Sierra Mist for the duration of the promotion because there really is no reason to purchase any other product since none of them are possibly giving you back $3 worth of music per 6 pack!
That is very clear. It also isn't very correct, or at least it is very much a guess. McD's could have the peel off on the drink rather then the fries. Or on both. Or a card they toss into the bag with each order. Or - get this - they could have come up with some totally new promotional gimmick (ok, not likely, but possible).
I would much rather have the unclear "I donno exactly how they are gonna do it" then the perfectly clear random guess.
Yep, you'll be able to quite easily prove that the pr0n was never on your computer
Probbably not, only "is not currently on, not even in the unused space where you can see bits of deleted files". (which ought to be good enough)
the problem is that you'll have to wait until *after* the authorities have broken down your door at 6am and taken away all your computers for analysis
Yeah, ok, I can see that. It took Steve Jackson Games what a year to get their stuff back? That wasn't kiddie porn either, it was "hacking" (or writing a game that had a hackign aspect that was so totally unlike real hacking it couldn't hav e even helped anyone who wanted to learn).
Guys, wifi is limited in scope to that which is not more than a few hundred yards from the access point.
Type "bi-quad antenna primestar" into google. Only one end needs that to go a signifigant distance. Way way way more then a few hundred yards.
The *same* limitations of passwords on the public Internet, however, are much more likely to be damaging.
Fewer people are in a position to see that traffic (not no people mind you, just fewer). Or at least fewer people that won't lose their job if they are cought. I'm more worried that someone a half mile away who has nothing better to do on their weekend is gonna try to spy on people for the hell of it then someone 57 miles away who works for the Telco and if they choose to peek in on peoples porn^H^H^H^Hweb surfing risks their job.
Wait a minute. Person A has an open WAP. Person B downloads kiddie porn using person A's WAP. Assuming person A doesn't have a caching web proxy how does person A posess anything that person B downloaded? It isn't on his WAP (granted it was in his WAP's RAM for a few milliseconds), it isn't on his laptops, it isn't on his desktops, it isn't printed out in his house, it isn't hiding in his car.
Wouldn't that be like charging person A for kidnapping if person B drove across his lawn with a trussed up body in their trunk?
It doesn't pass the sniff test.
Now this being "anything to protect the children" America I can see them charging Person A with something else, some sort of aiding charge or something. (actually I guess they could charge you with anything, but getting a judge to not laugh at possesion when nothing is possesed seems like a long shot)
Obviously the file that it's writing could be corrupted, but the existing files that are only being read shouldn't be affected. And in fact, I doubt that it actually does, and I think the assertion that FileVault is causing data loss due to users resetting the computer is incorrect.
The problem is FileVault is intended to work even if you want to encrypt your 15G home directory and your loptop only has a 20G disk. Clearly it has to do some removal of files as it goes.
As far as I can deduce from the warnings FileVault gives you before it starts (and from tales of woe from others) it does not do the smart thing and checkpoint itself. Apparently if you stop it in the middle you lose data (it is unclear wether you lose just a few files, or everything it has "coverted" so far, or "everything"...I susspect that you can actually recover a lot from the not-yet-complete FileVault, but nobody that this has happend to has attempted that yet).
This is on no way a troll but what exactly is expose. I have not used Mac os X, i use a gnome desktop. If I understand it correctly expose is a way to fix window clutter.
It doesn't solve or even address window clutter. It solves finding the window you want.
For example when I code I normally use two terminal windows, one on the left for the code, one on the right to run the program in the debugger, look at the output, or even bring up man pages. Expose doesn't get in the way of that, it still lets me put the windows where I want. Nor does expose help me use the two windows, I mean who needs anythign fancy to switch between two side by side windows? In OSX I use the command keys, in X I throw the mouse from side to side. It is only when I want to switch to things I use less (the mail app, a web browser, a calculator if I don't end up using bc...) that I bother with expose. Even then a lot of times I use command-tab.
On my Gnome desktop I don't have windows clutter. I don't move my windows around much. Every major program I use have its own workspace.
So, ok, if you didn't have cluttered windows you wouldn't have as much problems finding the one you wanted, but expose doesn't alter the way you lay out your windows which is actually a big win for people. It isn't a new thing to get use to when you start putting windows where you think you want them, only for when you want to find them. Even then only for when they are not already where you want them.
Virtual desktops (which I assume Gnome workspaces are) help you lay out windows in a new (to most people, I know vtwm used it 10+ years ago, as did tvtwm which I once maintained) way. If you take to that kind of layout then it is a big help to you. For some people it can get in the way. The new way does reduce clutter, and to an extent it helps you find windows. You know "my web browser is over there" and "my xterms for the servers are down there" and "GIMP is over there". On the other hand if you just started playing with a new program, you may not have memorised where you are keeping it, and you'll have to look at the little virtual desktop manager, or pan through how ever many workspaces you keep to find it.
Nothing would prevent expose form working with virtual desktops, which might help if you had some with more windows then you could easally pick from.
It might not help you, but I'm sure not all people who use GNOME experiance "no window clutter", and even if they all keep their windows layed out nicely I'm sure they can't always find every window they want quickly.
Now if Avid could update ProTools, and I can get ssh to listen over port 23 again (my place of employment has telnet open, but nothing else - I need to read slashdot!)
Doesn't adding "Port 23" to/etc/sshd_config do it? (not that I have tryed, but a quick scan of hte man page says it will... oh, you probbably have to HUP sshd). Or are you asking how to get the client to use another port (-p 23 I think).
Or they could just keep selling IPs at premium and make even MORE money.
Not really. When you have more then one place to go to buy the same thing ("Internet Connectivity" in this case) the companies (or people) that sell them have a few ways to get more consumers to buy. A fairly successful way to sell more is to lower the price. So if two companies sold DSL connections and one gave you a single IPv6 address plus as many more as you wanted at $1/month each and the other sold gave away one plus sold them for $0.50 each the more costly company is going to lose customers (all other things being equal of corse...if they provide more bandwidth or mail server space or uptime they might not lose customers). When they start losing customers they will look around and decide to drop the price to at least match the other guys. Of corse those other guys liked getting more customers, so they will drop their price some more. Both companies will likely repeat that process until they are selling the item at their cost, or until the differences are too small for people to notice (23 IPv6 addresses for $0.01 vs. 24 IPv6 addresses for $0.01).
Of corse this will not happen when there isn't a real choice in providers (say a Cable-only area, or DSL-only and of corse with only one Cable or DSL provider), it will also happen faster in areas with multiple providers...
You have to think like a corporation, not like a hopeful user.
Fortunitly you don't have to think like a corporation, but like a bunch of corporations greedily attempting to get the most money from a bunch of tight fisted users each attempting to get as much service as they can use for as close to as free as they can manage.
It is the same reason why a newer cheaper pesticide will make farmers more money for a short period of time, but then merely result in lower food prices for the rest of us (er, and maybe six legged frogs...maybe I need to find an example that has fewer environmental issues...)
One of the first X protocol extensions was allowing you to have windows that were some shape other than square. It broke no existing X applications at all,
Well to be fair it didn't exactly work with window managers that didn't know anything about shaped windows. It didn't cause the WM to not work, but it pretty much caused the managed windows not to be shaped (except I think uwm which didn't reparent windows...). So it could be said to have broken a tiny handful of programs ("almost all X window managers").
It definitly broke as few things as such a change could have though. Just like future changes are unlikely to break anything that doesn't use them except in a lot of cases they will require help from window managers (lest you get partly transparent windows in a fully opaque window border for example)...and I expect there may be a few other places where the new and the old don't interact very well (for example if a second attempt is made at fixing cut and paste).
It is still hard to imagine a scheme where that sort of extention broke nothing though.
FileIDs are not inodes. They are NOT equivalent as I pointed out elsewhere.
Um, all I saw you say that one can do with FileIDs that you can't do on most Unixish systems is #1 open files directly by them, and #2 convert them to a name without a full scan of the filesystem. Am I wrong?
If I'm right they are equivalent data structures, but the operations you want are not normally available. Wit pretty minimal work one could put both operations into an Open Source Unixish system. I would say 3 hours work tops to "open by inode" (which SunOS and Solaris both have), and I think about a week for fd2name but I would have to reread some papers or even try it to be sure.
That'll also read them even if they don't need to be defraged. This may be better:
sudo find / -exec head {} >/dev/null \;
Left as an exercise to the reader:
only run on stuff less then 20M (not that that will save you much, but it is a good way to learn how to use random tools)
Sort by access time, and head the files in that order so the most recently (and hopefully frequently) accessed files have more chance of being defraged then the older files
Parallelise it, and see how much slower (or faster!) it goes with diffrent numbers of concurrent accesses.
Sounds like compiling to me. Typical usage for a developer.
I don't think so. The source code files are generaly written in their entirety by the editor even if you only make changes starting halfway though a file (or add a few functions on the end). So they will normally only occupy one extent (i.e. be unfragmented), and are stunningly unlikely to have mroe then 7 extents (needed for auto-defrag to kick in). The object files are again only written in their entierty. The.s files (if written) are the same.
I think there is seaking around when you write the executable out, but only to fill in the jump addresses, and they are overwrites not appends. Unlikely to be much fragmentation there.
The systme include files and lib files ought not be fragmented, but if they this would fix that the first time you use each such file, and since they are all unfragmented next time through you won't have a problem there (it might even eventually save you some time).
I don't think a developer will run into this much (if at all!) during compiling.
There are some Unixes that let you open a file give it's i-number (er, and device number, or a path to the devices FS, I forget which). There are also some Unix-ish OSes (Plan9!) that let you get a part for any open file.
If you had those two primitaves would not FileIDs and i-numbers be the same? Or is there more to a FileID?
A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
Maybe. It is also why if I take CoolApp and rename it to CoolApp.old and install the new CoolApp in the same place as the old one all manner of stuff still runs CoolApp.old! I assume it will also sometimes be unable to find a file if I end up moving someting ontop of the old one (unless things that keep FileIDs keep both the FileID and a path to the file in case the FileID goes stale...which may be the case because I don't recall this happining, unlike the CoolApp.old bit)
Not if you do it intelligently (copy data, compare to original, delete original as an atomic operation).
The algo Apple uses is get a write lock on the file, write the current data out as if it were being appended (which attempts to write it in as few chunks as possiable), then get a read lock on the file, then free up the "old part" of the file and adjust meta data to make the newly written blocks be the start of the file. I assume something prevents the file from looking twice as long as it should during the copy, but I didn't see it in the code (it is probbably as simple as "ExtendFileC doesn't update that kind of metadata anyway lunkhead!"). That is done in the kernel context of the process that did the open, so it delays the return of that syscall, which is a shame.
OS X allows moving the physical data around of an open file ?
Yes since they are only logically addressed! It will prevent writes during the operation (and reads during a very small bit of time).
And while the read adds no time, the subsequent seeking, rewriting and deleting certainly does.
The read adds time if the process wouldn't have read that part of the file anyway (for example if it reads a bit of header data and closes the file). The rewriting may well be absorbed by the buffer cache (it is elligable for it) along with it's seeks and the time it later takes to actually happen might end up being zero (file deleted), or face no contention for the disk and end up being free. The deleting goes to the journal, but since lots of other things go there all the time that may be "mostly free".
So the costs may be low, but are more likely to be percieved then something that does it when the box is idle. Of corse there is the chance that the box is never idle. For example a 24/7 server that gets used 24/7, or a laptop that is never powered up except when it is in use. So delaying something like that "until idle" might delay the benifits of defrag not just "for a while" but "forever".
I donno which is actually better. I think with some tuning to only do "as you go defrag" when there isn't a lot of pending I/O could definitly make it the more likely winner, but it will still depend on usage patterns. One could also tune the "only when idle" method to do "just a little" if it has been "too long" since the last time it was idle.
Slashdot Mirror
It is an older concept (20 years or maybe 30!), look up barrel processors sometime. I'm pretty sure the MTA executed one thread per CPU per cycle with no penality for switching between threads on diffrent cycles. It would switch threads any time a load was issued, any time the store buffer was full and a store was issued, and after X cycles. The resources you need for an MTA thread would be more or less an extra set of registers.
SMT (at least as the Alpha EV8, and IBM Power5 do it, I'm not sure what Intel's HT is exactly, but I think it is the same) executes more then one thread every cycle. So you need not only an extra register set per thread you need to make the "dispatch this to an ALU" logic more complex, and I think that is non-linear. I don't know why two seems to be the magic number and not 4 or something, but the higher cost per thread in SMT shows why you don't just add a ton of threads.
Hope that helps.
I agree that patching will be easier, unless you patch a library bug that shows up in the new /recovery tools. I'm not so sure about making the overall disk space requirement smaller, if the /recover tools are even close to the full set of stuff that is now dynamically linked the total disk use is higher. The only saving grace there is you might not put /recover on the same disk partition as /. Not really a win.
So patching is in some cases better, total disk space usage is probably up, and performance is probably down a little bit (unmemorable unless you are looking for it). Not in my opinion a good change, but not bad enough to send me scurrying off to AnotherBSD, not by a long shot. In the grand scheme of things it is a tiny change.
The last paper I read on dynamic linking showed about a 2% penalty on RISC CPUs and a bit over 10% on CISCs (losing one of 16+ registers to hold a libs base pointer hurts less then losing one of "about 4 to 8" registers!). That was a long time ago though, around when Sun added them to SunOS, maybe the early 90s or late 80s. Very short running programs (ls and echo) were hurt a lot more. Oddly enough some very small programs (like cat and echo) were larger as dynamic linked code (more disk space used to record the static code to invoke the dynamic linker, and to hold the symbols to link).
It mattered to me more then too. I didn't have SunOS source so any lib bug I wanted to fix, or lib call I wanted to improve wasn't gonna happen for the static programs.
Um, so are CD-R and DVD-R, but I don't see people complaining. As long as this thing has a low enough price it will replace those things just fine. That is it's most likely target market.
If it is cheap enough it could replace FLASH since FLASH has a limited number of erase cycles, so if 100000 times as much of this new memory cost less then FLASH that could only be written 100000 times it is a win... but that seems less likely.
PROMs are solid state and "write once", EPROMS are solid state and while they are "write many" they need exposure to strong UV light so they tend to be "write once" in field equiptment. MROM is "write when fab'ed". PROM, EPROM (and EEPROM) have all more or less vanished as FLASH ROM became dominant because it was re-writable. MROM is still seen from time to time because it is dirt cheap in quantity.
Er, and don't forget the other notable anomaly, one of the first iTunes updates forgot to handle spaces in file names (which are common on Macs) and could delete vast swaths of your stuff.
Other then those two I can't think of any bad upgrade experiences from Apple.
Think about hardware at the gate level, your adders are a bunch of flip flops. A whole lot of them. And very very tiny ones holding very little charge. A cosmic ray striking one can change it's value (I think only form one to zero, or zero to one depending on the process and wether charged or discharged represents a zero or a one). If the cosmic ray hits one of the flip flops that is being used to produce a value about to go to a live register and then off to memory it can change the results from what your code should calulate to something with a one bit error. Maybe a low bit and the result is off by pennies, maybe a high bit and the result is so amazingly off that an assert later in the code catches it, or just a human eyeballing the results would. Worse yet something in the mid rage that nobody notices until far too late (if ever).
This is the same thing that ECC in memory helps prevent (ECC can't protect against multiple bit failures, but while a box with multiple gigs of memory will likely get a soft memory error in your lifetime, multiple bit errors before the scrubber finds them is really really really amazingly unlikely).
It is a force that gets worse as we go to lower voltage systems (less of a hit needed to flip values), and as we get greater densities (more likelyhood of the cosmic ray hitting something other then dead space -- at least I think so on this one).
It can be combated by having ECC on register and cache values (or even parity as long as the bits are "big enough" that a single cosmic ray hit won't flip multiple bits!), but having similar checks on ALU operations, or just sending the values through identical ALUs that are on diffrent parts of the chip and compairing them after (rerun any cycle where the results differ, either totally in hardware or trapping to the OS to let it restart the instruction after logging the hit). Not rocket science, but it makes for a more costly CPU, and it makes for a slightly slower CPU (in fact much slower when you factor in the extra transistors used for correctness checks that a "normal" CPU would use for cache or some other performance boosting geegaw).
As for documentation I don't recall where I saw studies done, probbaly in one of the ACM or IEEE procedings, but if you don't have access to them comp.risks might turn something up (and a lot of other stuff that might be more worth worring about :-)
This specific problem was that most window managers (all except UWM as far as I know) want to display decorations on the managed windows (resize, iconify, title bars, and so on). To do so they reparent the managed (application) windows so that they are contained inside windows the window manager owns (and therefore windows the WM can draw in without bothering the applications they manage).
When a window manager written prior to shaped window extentions (or that just doesn't care) reparents a shaped window you get a non-rectangular child window inside a rectangular window that the window manager owns. That rectangular window will pretty much make the child's shaped window look rectangular.
There isn't much you can do about that if you want to allow pre-extention applications (like window managers) to work with post-extention applications (the managed apps). There isn't any "checking of paramaters" the window managers could have done in 1990 that would prepair them for the 1991 addition of shaped windows. Nor is there much of anything that an X window manager can do in 2003 to make it work and play well with stuff using extentions that might be released in 2004 or 2037.
Well if you really like a window manager that is no longer being maintianed then there may never be a #define! Of corse historically the extentions don't not work, they are just visually a little iffy (windows that should be round aren't), and in the future that is likely to still be the case (transparent windows with very solid title bars).
Sure, but what aobut something like libmng which doesn't have that much in the way of people looking at it, yet is stuck into Mozilla (some versions at any rate) and fed datastreams directly from the web? And how many people pour over tcsh's sources for security holes?
Last I attempted it 18 years ago or so yes, I could (it was just "CONNECT", not "CONNECT 300/NONE", either the extended status code hadn't been invented, or I didn't know how to turn it on at the time).
I don't think I have the lung capacity to whistle long enough for a modern modem to ratchet back to 300 baud though!
I think I use to be able to send the letter A as well, well a buch of @ signes and stuff, but I use to be able to make it do more a fewer A's for some reason. Then again it's a bit over half my lifetime ago, so I don't remember that part clearly....
They can, and it will prevent further damages from pileing up, but how does stopping steeling eliminate any past penalties? If the RIAA storms your house can you just say "sorry, the next version of my music collection will no longer include stolen music, please move on"? (ok, maybe I should have used a less hated group for an example, but...)
So they rip off free software, find out a feature is desired, and then write the code themselves. Very inexpensave prototypeing :-)
Rats, you beat me to it :-) I susspect that since they aren't SCOlike slime, but a company that looks like it thought it was doing the right thing by publising their iterm changes and such that the iterm authors will probbably let them get away with just no longer offending and not actually worry about "past damage".
Well with iTMS you are allowed to burn the music to a normal audio CD, so if you want a physical tangable non-revokable form for your downloaded music, have at it.
Of corse if you ever have to re-convert it to AAC or something it will sound worse then the original, but them's the breaks. (oh, and you have to factor in the $0.05/disc for the CD-R)
For me I'll buy it from iTMS if I didn't want the rest of the alblum, or if it is a lot cheaper, or if I'm too impatent to go to the store...er...wait...that doesn't leave a whole lotta times I'll buy a physical CD now!
That is very clear. It also isn't very correct, or at least it is very much a guess. McD's could have the peel off on the drink rather then the fries. Or on both. Or a card they toss into the bag with each order. Or - get this - they could have come up with some totally new promotional gimmick (ok, not likely, but possible).
I would much rather have the unclear "I donno exactly how they are gonna do it" then the perfectly clear random guess.
I can whistle a 300 baud carrier, maybe the original poster can negotiate PPP as well...
Probbably not, only "is not currently on, not even in the unused space where you can see bits of deleted files". (which ought to be good enough)
Yeah, ok, I can see that. It took Steve Jackson Games what a year to get their stuff back? That wasn't kiddie porn either, it was "hacking" (or writing a game that had a hackign aspect that was so totally unlike real hacking it couldn't hav e even helped anyone who wanted to learn).
Type "bi-quad antenna primestar" into google. Only one end needs that to go a signifigant distance. Way way way more then a few hundred yards.
Fewer people are in a position to see that traffic (not no people mind you, just fewer). Or at least fewer people that won't lose their job if they are cought. I'm more worried that someone a half mile away who has nothing better to do on their weekend is gonna try to spy on people for the hell of it then someone 57 miles away who works for the Telco and if they choose to peek in on peoples porn^H^H^H^Hweb surfing risks their job.
Wait a minute. Person A has an open WAP. Person B downloads kiddie porn using person A's WAP. Assuming person A doesn't have a caching web proxy how does person A posess anything that person B downloaded? It isn't on his WAP (granted it was in his WAP's RAM for a few milliseconds), it isn't on his laptops, it isn't on his desktops, it isn't printed out in his house, it isn't hiding in his car.
Wouldn't that be like charging person A for kidnapping if person B drove across his lawn with a trussed up body in their trunk?
It doesn't pass the sniff test.
Now this being "anything to protect the children" America I can see them charging Person A with something else, some sort of aiding charge or something. (actually I guess they could charge you with anything, but getting a judge to not laugh at possesion when nothing is possesed seems like a long shot)
The problem is FileVault is intended to work even if you want to encrypt your 15G home directory and your loptop only has a 20G disk. Clearly it has to do some removal of files as it goes.
As far as I can deduce from the warnings FileVault gives you before it starts (and from tales of woe from others) it does not do the smart thing and checkpoint itself. Apparently if you stop it in the middle you lose data (it is unclear wether you lose just a few files, or everything it has "coverted" so far, or "everything"...I susspect that you can actually recover a lot from the not-yet-complete FileVault, but nobody that this has happend to has attempted that yet).
It doesn't solve or even address window clutter. It solves finding the window you want.
For example when I code I normally use two terminal windows, one on the left for the code, one on the right to run the program in the debugger, look at the output, or even bring up man pages. Expose doesn't get in the way of that, it still lets me put the windows where I want. Nor does expose help me use the two windows, I mean who needs anythign fancy to switch between two side by side windows? In OSX I use the command keys, in X I throw the mouse from side to side. It is only when I want to switch to things I use less (the mail app, a web browser, a calculator if I don't end up using bc...) that I bother with expose. Even then a lot of times I use command-tab.
So, ok, if you didn't have cluttered windows you wouldn't have as much problems finding the one you wanted, but expose doesn't alter the way you lay out your windows which is actually a big win for people. It isn't a new thing to get use to when you start putting windows where you think you want them, only for when you want to find them. Even then only for when they are not already where you want them.
Virtual desktops (which I assume Gnome workspaces are) help you lay out windows in a new (to most people, I know vtwm used it 10+ years ago, as did tvtwm which I once maintained) way. If you take to that kind of layout then it is a big help to you. For some people it can get in the way. The new way does reduce clutter, and to an extent it helps you find windows. You know "my web browser is over there" and "my xterms for the servers are down there" and "GIMP is over there". On the other hand if you just started playing with a new program, you may not have memorised where you are keeping it, and you'll have to look at the little virtual desktop manager, or pan through how ever many workspaces you keep to find it.
Nothing would prevent expose form working with virtual desktops, which might help if you had some with more windows then you could easally pick from.
It might not help you, but I'm sure not all people who use GNOME experiance "no window clutter", and even if they all keep their windows layed out nicely I'm sure they can't always find every window they want quickly.
Well, plus, it looks way cool :-)
Doesn't adding "Port 23" to /etc/sshd_config do it? (not that I have tryed, but a quick scan of hte man page says it will... oh, you probbably have to HUP sshd). Or are you asking how to get the client to use another port (-p 23 I think).
Good luck.
Not really. When you have more then one place to go to buy the same thing ("Internet Connectivity" in this case) the companies (or people) that sell them have a few ways to get more consumers to buy. A fairly successful way to sell more is to lower the price. So if two companies sold DSL connections and one gave you a single IPv6 address plus as many more as you wanted at $1/month each and the other sold gave away one plus sold them for $0.50 each the more costly company is going to lose customers (all other things being equal of corse...if they provide more bandwidth or mail server space or uptime they might not lose customers). When they start losing customers they will look around and decide to drop the price to at least match the other guys. Of corse those other guys liked getting more customers, so they will drop their price some more. Both companies will likely repeat that process until they are selling the item at their cost, or until the differences are too small for people to notice (23 IPv6 addresses for $0.01 vs. 24 IPv6 addresses for $0.01).
Of corse this will not happen when there isn't a real choice in providers (say a Cable-only area, or DSL-only and of corse with only one Cable or DSL provider), it will also happen faster in areas with multiple providers...
Fortunitly you don't have to think like a corporation, but like a bunch of corporations greedily attempting to get the most money from a bunch of tight fisted users each attempting to get as much service as they can use for as close to as free as they can manage.
It is the same reason why a newer cheaper pesticide will make farmers more money for a short period of time, but then merely result in lower food prices for the rest of us (er, and maybe six legged frogs...maybe I need to find an example that has fewer environmental issues...)
Well to be fair it didn't exactly work with window managers that didn't know anything about shaped windows. It didn't cause the WM to not work, but it pretty much caused the managed windows not to be shaped (except I think uwm which didn't reparent windows...). So it could be said to have broken a tiny handful of programs ("almost all X window managers").
It definitly broke as few things as such a change could have though. Just like future changes are unlikely to break anything that doesn't use them except in a lot of cases they will require help from window managers (lest you get partly transparent windows in a fully opaque window border for example)...and I expect there may be a few other places where the new and the old don't interact very well (for example if a second attempt is made at fixing cut and paste).
It is still hard to imagine a scheme where that sort of extention broke nothing though.
Um, all I saw you say that one can do with FileIDs that you can't do on most Unixish systems is #1 open files directly by them, and #2 convert them to a name without a full scan of the filesystem. Am I wrong?
If I'm right they are equivalent data structures, but the operations you want are not normally available. Wit pretty minimal work one could put both operations into an Open Source Unixish system. I would say 3 hours work tops to "open by inode" (which SunOS and Solaris both have), and I think about a week for fd2name but I would have to reread some papers or even try it to be sure.
That'll also read them even if they don't need to be defraged. This may be better:
sudo find / -exec head {} >/dev/null \;
Left as an exercise to the reader:
I don't think so. The source code files are generaly written in their entirety by the editor even if you only make changes starting halfway though a file (or add a few functions on the end). So they will normally only occupy one extent (i.e. be unfragmented), and are stunningly unlikely to have mroe then 7 extents (needed for auto-defrag to kick in). The object files are again only written in their entierty. The .s files (if written) are the same.
I think there is seaking around when you write the executable out, but only to fill in the jump addresses, and they are overwrites not appends. Unlikely to be much fragmentation there.
The systme include files and lib files ought not be fragmented, but if they this would fix that the first time you use each such file, and since they are all unfragmented next time through you won't have a problem there (it might even eventually save you some time).
I don't think a developer will run into this much (if at all!) during compiling.
There are some Unixes that let you open a file give it's i-number (er, and device number, or a path to the devices FS, I forget which). There are also some Unix-ish OSes (Plan9!) that let you get a part for any open file.
If you had those two primitaves would not FileIDs and i-numbers be the same? Or is there more to a FileID?
Maybe. It is also why if I take CoolApp and rename it to CoolApp.old and install the new CoolApp in the same place as the old one all manner of stuff still runs CoolApp.old! I assume it will also sometimes be unable to find a file if I end up moving someting ontop of the old one (unless things that keep FileIDs keep both the FileID and a path to the file in case the FileID goes stale...which may be the case because I don't recall this happining, unlike the CoolApp.old bit)
The algo Apple uses is get a write lock on the file, write the current data out as if it were being appended (which attempts to write it in as few chunks as possiable), then get a read lock on the file, then free up the "old part" of the file and adjust meta data to make the newly written blocks be the start of the file. I assume something prevents the file from looking twice as long as it should during the copy, but I didn't see it in the code (it is probbably as simple as "ExtendFileC doesn't update that kind of metadata anyway lunkhead!"). That is done in the kernel context of the process that did the open, so it delays the return of that syscall, which is a shame.
Yes since they are only logically addressed! It will prevent writes during the operation (and reads during a very small bit of time).
The read adds time if the process wouldn't have read that part of the file anyway (for example if it reads a bit of header data and closes the file). The rewriting may well be absorbed by the buffer cache (it is elligable for it) along with it's seeks and the time it later takes to actually happen might end up being zero (file deleted), or face no contention for the disk and end up being free. The deleting goes to the journal, but since lots of other things go there all the time that may be "mostly free".
So the costs may be low, but are more likely to be percieved then something that does it when the box is idle. Of corse there is the chance that the box is never idle. For example a 24/7 server that gets used 24/7, or a laptop that is never powered up except when it is in use. So delaying something like that "until idle" might delay the benifits of defrag not just "for a while" but "forever".
I donno which is actually better. I think with some tuning to only do "as you go defrag" when there isn't a lot of pending I/O could definitly make it the more likely winner, but it will still depend on usage patterns. One could also tune the "only when idle" method to do "just a little" if it has been "too long" since the last time it was idle.