Right hand monitor has firefox + 1 xterm for the local screen sessions, and another for the remote screen sessions.
The Left hand monitor is almost always used to show a game either fullscreen, or preferably 'maximised' (i.e. no border, title bar etc) windowed. In that latter case I can luckily still get at the start menu with Ctrl-Esc, which also gives access to the Quick Bar and Systray if needed.
Basically if I'm in Windows (XP Pro) it's to play a game that requires Windows so I'm not farting around with virtual desktops or lots of windows.
Linux: Each Monitor is a separate X display, and each of those runs fvwm2 with a 3x2 set of virtual desktops. Monitor 1, Desktop1: 3 principal xterms for IRC/local email/other stuff, these are actually open all the time rather than ever minimised, oh and they're all attached to the same local screen sessions. And then there's the mostly-minimised ones: a spare user xterm and a root xterm on each of my local machines. Desktop2: Couple of xterms ssh'ing to the server that holds my 'real' email, where I read news, that I help admin etc. Both are attached to the same screen session (-x) on there. Desktop 3, 5 and 6: Empty, but will be taken up by things like GNUCash, GIMP or whatever extra programs I run. Desktop 4: One wiiiiiiiiiiide xterm for ease of reading compilation output. Another normal (80x24) xterm for general shell user, and I'll fire up any number of other xterms here as needed when coding.
Monitor 2, Desktop 1, 3, 5, 6: Empty for spare use as above. Desktop 2: Actually this is where the most used xterms+ssh to my email host run, the Monitor 1 versions are only used if I really need to see that stuff on Monitor 1 whilst looking at other things on Monitor 2. Desktop 5: 1 Firefox window with as many tabs as I need, maybe the occasional extra window, plus the occasional temporary xterm.
Note that I'd actually like to just use the one fvwm2 instance and the one 3x2 pager of virtual desktops, but be able to arbitrarily show any desktop (including the same one) on either monitor. Yes, I've tried Xinerama, but that just makes each desktop span the two monitors and what both of them displays would change on paging around. If anyone knows a window manager that will achieve what I WANT (likely via enabling Xinerama and then the WM re-splitting the display into an area per Display) I'd LOVE to hear about it.
Anyway, to total up: 12 xterms, 1 Firefox window (with however many tabs I need), the FvwmPager on each Display and an xclock which shows on every desktop on the first Display. There's a lack of any permanent music player because I use a web-controlled jukebox for that.
High energy particle accelerators are vital for cutting edge physics and many types of medical therapy, and miniaturizing them would be a boon for both basic physics research and medicine.
I'm just waiting for the day it's revealed that Jack has actually been in the pay of various computer game producing companies all along. Paid to drum up extra publicity for them.
Seriously, not being into the genre, I'd never have heard of this new MK game if not for his latest shenanigans.
Oh shit, did I just give him an idea for his next law suit? Suing said games companies for lack of payment for the promotion he's been doing for them....
In my experience you can't just write one CV/Resume. You always have to tailor it. Try to submit one that company A loved in the past to Agency/Company B and they'll complain it shows "too much of X, and not enough of Y". Tweak it to their specs and the next lot will complain it has "too much Y", then the next will say "where's the Z section?", and you'll go and add that in, to which the next will say "Sorry, because you included Y and Z it's too long, we only check the front page" (which is the reason for that brief listing of skillsets people use).
Like others have said, the only way to be sure the applications will be amenable to you looking over them quickly, and later in detail, is to have CV/Resumes submitted directly to yourself and pre-specify the format you expect.
What's needed is an ISO (eek!) standard CV format, and for all agencies and HR depts to accept it without whining.
Admittedly so long as the normal user account's password is chosen well, never sent in plaintext over the network etc there's not much problem with this, but...... that just means someone ONLY needs to compromise the/a user account to get root! It's the reason I have a seperate uid 0 account on my web/shell host machine for me to root with[0], rather than use sudo. Particularly as there is the vague chance that I'll now and then need to access my normal account from somewhere where I can only non-SSL telnet/pop3/imap/whatever. This way I can do that, in the knowledge someone might sniff the password and compromise *my* account, but they won't get root from it.
[0] Separate account so I can change the password without affecting the other admins of the machine. We used to all have our own uid 0 account, but the rest of them seem to prefer the sudo 'risk'. The one paying for the machine knows the actual root password.
Aye, my PII-400 with 384MB RAM makes a brilliant firewall/router/nfs/smb/shell machine. The only problem I have is staying on 'old' kernels because it's so stable and I don't want to reboot it. I really should update it to something more recent (but given I keep an eye on linux-kernel and BUGTRAQ I'm fairly confident it's not affected by any currently patched holes, like all that SCTP stuff? I don't use it, not even loaded the module if I even compiled one).
Of course it wouldn't crawl *too* much if *I* used it for a desktop either, but then I still use fvwm2 rather than KDE/Gnome with all their cpu-murdering bells and whistles.
And how is anyone, myspace included, meant to vet the contents of URLs that they don't control?
Anyone intending malicious conduct can easily *change* the code that produces the URL's content so that at the initial checking stage it all looks harmless, but sometime after that once it's live they make it start exploiting security holes.
I guess you could insist that anyone running ads on the web has to be directly responsible for their generation, and thus there'll be no more general ad serving companies, but the likes of myspace, and certainly smaller sites, likely don't want to do that.
Amen to that. Ever played Battlefield 2 on anything less than the very latest hardware, motherboard, CPU, RAM and GPU-wise ?
Easily over a minute loading a map, almost as easily over 2 minutes. And this is on the kind of game where most folks are used to it taking 15 seconds tops, and *that* would be classed as slow.
If you check Copyright, Designs and Patents Act 1988 (c. 48) and The Copyright and Related Rights Regulations 2003 you'll see that there isn't any 'fair use' right for CD/tape/vinyl music in the UK. The closest is that for making recordings of 'broadcasts' (includes cable tv). A phrase similar to 'fair use' is 'fair dealing', which is applicable in general to academic works (and has some new restrictions due to that EU directive).
So, yes, this is/was news, the BPI is basically saying they're waiving their right to sue anyone for what is, legally speaking, an infringement.
And indeed that EU directive has given us a clause prohibiting reverse engineering "the functioning of a computer program".
Ah, one thing occurs to me. The majority of DSL in the UK is 'resold' from BT's infrastructure. As it's their equipment at the DSL/DSLAM level it'll be them that are doing this "give them some extra speed to account for overhead", so you get it no matter what ISP you're using (and no doubt OfCom would frown upon any ISP trying to claim they sell the 'faster' speed when everyone else is honest about it). I wonder if LLU-provided DSL is generally the same ?
Indeed, I'm in the UK on Zen Internet, and when I look at my actual line speed on my DSL router I get told my 1Mbps/256Kbps connection is sync'ing at 1152/288 Kbps.
A cursory check with OpenSSH on my debian box showed you can set the environment variables and gain access to an ssh-agent you "shouldn't" have access to. Although the way I tested it OpenSSH may still have been doing 'something clever' in the background (ssh -a localhost to get a fresh login without contact to the previous ssh-agent, change the "env | grep SSH" variables to those from the previous ssh-agent, try ssh to a remote machine that the ssh-agent is set up for and I got in).
So, if Mr. Stupid-Admin on IW is doing this tunneling trick, or otherwise simply has his IW ssh-agent set up to allow instant ssh (via key pairs) to D1 and D2, then if he is currently logged into D1, with agent forwarding enabled, and an attacker has compromised that machine D1, then iff D2 allows ssh connections from D1 using the same key as for IW -> D1, the attacker can hop from D1 to D2 (as he can use the compromised ssh-agent/sshd on D1 to back-request the necessary key interaction on IW).
But, still, this is all about incompetent sysadmins. First if there's no reason to allow ssh from D1 to D2 (to Dn in the general case), firewall it off where-ever possible. Secondly who'd be stupid enough to set it up so the IW -> D1 key pair will also authenticate D1 -> D2 ? An incompetent sysadmin, that's how.
Anyway, all this aside, I think the original/. poster got confused and tried to make out the article is about a flaw in ssh, it's not. The article is about how Mr. Incompetent Sysadmin can easily configure ssh/ssh-agent/keys/firewalls to enable security holes that wouldn't be there if ssh didn't do all this frightfully clever port forwarding, agent forwarding, and public/private keypair authentication. Take the article as a heads up "If you do X, be careful because it may means someone else can do Y via it". To sum up "Incompetent Systems Administrators May Open Security Holes On Their Systems!".
Indeed, or even more precisely, the entire thing is about incompetent systems administrators.
If your DMZ box needs access to patches then sort out the patch server *pushing* them out. Or at the very least grab them on your workstation from the patch server, then push them to the DMZ host from there. Under no circumstances do this double-tunnelling tricks to allow the DMZ host *any* direct access to the internal patch server, even if it's to a single port, for a single daemon, that you think is coded correctly and thus secure.
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
Or better yet, don't allow the DMZ host to initiate *any* connection outbound from itself, if the services present on it don't need to do such, or failing that, disallow it initiating any connection that isn't out the internet-only-facing interface(s).
However, that's still not what the attack is exploiting, and wouldn't prevent the attack.
The 'attack' is taking an (I)Internal (S)erver, an (I)nternal (W)orkstation, and a (D)MZ host. Your firewall/ACLs are set such that IS can't receive, or will reject, any connection from D. However IS will accept connections from IW, and furthermore IW can ssh to D. So, the well-meaning admin of D, using IW, ssh's to D, setting up a tunnel to forward traffic on port Dx on D back to IW, port IWx, and also ssh's from IW to IS, forwarding IWx to a service on IS. Thus you can now connection to (D's) localhost:Dx and end up talking to the service on IS.
At no point is any connection initiated from D outside of itself, as the data is simply passing back through the ssh tunnel from IW to D, and then back further from IW to IS. And, no, you can't firewall D from talking to any but necessary ports on D, as we're assuming root compromise of D and thus all such bets are off.
Now, if someone has compromised D *and* can hijack this tunnel D IW IS they have access to IS.
Of course the real solution to the base problem is to have IS set up in some way to push data out to D, such that IW's user/D's admin doesn't have to play such silly and dangerous games in the first place. Any such 'administrator' setting up what has been described is incompetent.
Now one last thing. The general attack hinges on an attacker's agent Aa being able to make use of the unix domain socket of the administrator's agent, Da. I'm very certain that when I tried this kind of attack on myself way back in 1998 or sooner it plain wasn't possible. If it is now then the (Open, whatever)ssh code has taken a step backwards. Basically some check was done on the origin of the messages on the socket, and if they weren't as expected the request to use the keys in the agent was denied. I think it was along the lines of "is the requesting process a (sub(sub...))child of myself?", presumably by following parent process IDs back up until it finds itself or init. Yes, ok, if the agent spawned any child that spawned a service that was subsequently compromised and not put in a new session group you could probably pull off the attack, but that is unlikely (as any service daemonising itself will end up in a new session group).
Still, for all practical intents and purposes, read-only.
Sure, there's 'write support', if you like replacing a file with one of the exact same length every time. No truncating, no extending. You might possibly be able to change the file length within the bounds of the block size, but I've not tested that.
Yes, so you can transfer files Windows -> Linux still, but not the other way using NTFS.
Personally I just use Samba on my file server which both can access.
Aha! Thankyou for the correction. I was thinking the constant check on any write would be more than a little stupid, I forget that it's MMUs pulling these tricks in the first place.
1) Read/. article 2) Check the linked-to article. Good, nothing about sending back a 'rejection' to the sender of an unapproved email, which you were going to bitch about on the grounds that it's as bad as spam itself. Remember that you DO harangue anyone running a whitelist anti-spam system that spams *you* when some spammer spoofs your email address in the From field. 3) Have it occur rather quickly to you that this 'key' system already exists, it's called PGP. 4) Look at/. comments, search for 'PGP' 5) Find this post.
also btw its every write to a new page that triggers a copy not every single write
I assumed the poster you're replying to was referring to the need to check the reference count on every write, not what you then do if the count was larger than one. That IS a large overhead, given it's for every write, it just gets worse on those writes that turn out to be to a currently shared page.
Indeed, I would say the spirit of the new ToS clauses is "we're now giving you this extra stuff for no charge, on the condition you allow these ads on your pages, anything you do to prevent people showing those adds is against our ToS and we'll terminate service to you, as otherwise you'd be getting the extras entirely free".
The one clause prohibits doing so directly in the LJ style code.
The second clause covers "hey guys, I know the ads are annoying, but you can block them like this...", which amounts to the same end result.
It's the primary reason I started using Junkbuster, and long-since switched to AdBlock.
"Why's this page loading so damned slow?... Ah, I see, it's due to the images/javascript loading for ads, or failing to, time to block that then".
Although having said that I find all animated ads entirely obnoxious. Sure, they're doing exactly what they're designed to do, draw my attention away from the rest of the page, but that's exactly what makes me block them. I don't want my attention drawn away in this manner.
I too initially started blocking ads (at the time with a junkbuster proxy) because many of the ad servers were just too damned slow. This meant that my browser would block waiting for an ad to load, and the actual content of the page would be delayed in loading. Very, very annoying.
Of course any time I see an ad now, given I'm used to them being blocked (with AdBlock these days) I find them annoying to see at all, as they only distract (by design) from the main page, especially if animated in anyway.
And then there's the point that the chances of my actually ever clicking on any ad are so vanishingly small that I'm actually saving the ad servers some amount of bandwidth money that would have been wasted.
Slashdot Mirror
Oops, forgot to add in the windows setup.
Right hand monitor has firefox + 1 xterm for the local screen sessions, and another for the remote screen sessions.
The Left hand monitor is almost always used to show a game either fullscreen, or preferably 'maximised' (i.e. no border, title bar etc) windowed. In that latter case I can luckily still get at the start menu with Ctrl-Esc, which also gives access to the Quick Bar and Systray if needed.
Basically if I'm in Windows (XP Pro) it's to play a game that requires Windows so I'm not farting around with virtual desktops or lots of windows.
2 Monitors, both at 1280x1024
Linux:
Each Monitor is a separate X display, and each of those runs fvwm2 with a 3x2 set of virtual desktops.
Monitor 1, Desktop1: 3 principal xterms for IRC/local email/other stuff, these are actually open all the time rather than ever minimised, oh and they're all attached to the same local screen sessions. And then there's the mostly-minimised ones: a spare user xterm and a root xterm on each of my local machines.
Desktop2: Couple of xterms ssh'ing to the server that holds my 'real' email, where I read news, that I help admin etc. Both are attached to the same screen session (-x) on there.
Desktop 3, 5 and 6: Empty, but will be taken up by things like GNUCash, GIMP or whatever extra programs I run.
Desktop 4: One wiiiiiiiiiiide xterm for ease of reading compilation output. Another normal (80x24) xterm for general shell user, and I'll fire up any number of other xterms here as needed when coding.
Monitor 2, Desktop 1, 3, 5, 6: Empty for spare use as above.
Desktop 2: Actually this is where the most used xterms+ssh to my email host run, the Monitor 1 versions are only used if I really need to see that stuff on Monitor 1 whilst looking at other things on Monitor 2.
Desktop 5: 1 Firefox window with as many tabs as I need, maybe the occasional extra window, plus the occasional temporary xterm.
Note that I'd actually like to just use the one fvwm2 instance and the one 3x2 pager of virtual desktops, but be able to arbitrarily show any desktop (including the same one) on either monitor. Yes, I've tried Xinerama, but that just makes each desktop span the two monitors and what both of them displays would change on paging around. If anyone knows a window manager that will achieve what I WANT (likely via enabling Xinerama and then the WM re-splitting the display into an area per Display) I'd LOVE to hear about it.
Anyway, to total up: 12 xterms, 1 Firefox window (with however many tabs I need), the FvwmPager on each Display and an xclock which shows on every desktop on the first Display. There's a lack of any permanent music player because I use a web-controlled jukebox for that.
High energy particle accelerators are vital for cutting edge physics and many types of medical therapy, and miniaturizing them would be a boon for both basic physics research and medicine.
What? No mention of use as weapons?
I'm just waiting for the day it's revealed that Jack has actually been in the pay of various computer game producing companies all along. Paid to drum up extra publicity for them.
Seriously, not being into the genre, I'd never have heard of this new MK game if not for his latest shenanigans.
Oh shit, did I just give him an idea for his next law suit? Suing said games companies for lack of payment for the promotion he's been doing for them....
In my experience you can't just write one CV/Resume. You always have to tailor it. Try to submit one that company A loved in the past to Agency/Company B and they'll complain it shows "too much of X, and not enough of Y". Tweak it to their specs and the next lot will complain it has "too much Y", then the next will say "where's the Z section?", and you'll go and add that in, to which the next will say "Sorry, because you included Y and Z it's too long, we only check the front page" (which is the reason for that brief listing of skillsets people use).
Like others have said, the only way to be sure the applications will be amenable to you looking over them quickly, and later in detail, is to have CV/Resumes submitted directly to yourself and pre-specify the format you expect.
What's needed is an ISO (eek!) standard CV format, and for all agencies and HR depts to accept it without whining.
Duh, you're obviously meant to upgrade to Office 2003, or whichever is latest, in which this will[0] be fixed.
[0] May be lies.
Admittedly so long as the normal user account's password is chosen well, never sent in plaintext over the network etc there's not much problem with this, but... ... that just means someone ONLY needs to compromise the/a user account to get root! It's the reason I have a seperate uid 0 account on my web/shell host machine for me to root with[0], rather than use sudo. Particularly as there is the vague chance that I'll now and then need to access my normal account from somewhere where I can only non-SSL telnet/pop3/imap/whatever. This way I can do that, in the knowledge someone might sniff the password and compromise *my* account, but they won't get root from it.
[0] Separate account so I can change the password without affecting the other admins of the machine. We used to all have our own uid 0 account, but the rest of them seem to prefer the sudo 'risk'. The one paying for the machine knows the actual root password.
Aye, my PII-400 with 384MB RAM makes a brilliant firewall/router/nfs/smb/shell machine. The only problem I have is staying on 'old' kernels because it's so stable and I don't want to reboot it. I really should update it to something more recent (but given I keep an eye on linux-kernel and BUGTRAQ I'm fairly confident it's not affected by any currently patched holes, like all that SCTP stuff? I don't use it, not even loaded the module if I even compiled one).
Of course it wouldn't crawl *too* much if *I* used it for a desktop either, but then I still use fvwm2 rather than KDE/Gnome with all their cpu-murdering bells and whistles.
And how is anyone, myspace included, meant to vet the contents of URLs that they don't control?
Anyone intending malicious conduct can easily *change* the code that produces the URL's content so that at the initial checking stage it all looks harmless, but sometime after that once it's live they make it start exploiting security holes.
I guess you could insist that anyone running ads on the web has to be directly responsible for their generation, and thus there'll be no more general ad serving companies, but the likes of myspace, and certainly smaller sites, likely don't want to do that.
Amen to that. Ever played Battlefield 2 on anything less than the very latest hardware, motherboard, CPU, RAM and GPU-wise ?
Easily over a minute loading a map, almost as easily over 2 minutes. And this is on the kind of game where most folks are used to it taking 15 seconds tops, and *that* would be classed as slow.
If you check Copyright, Designs and Patents Act 1988 (c. 48) and The Copyright and Related Rights Regulations 2003 you'll see that there isn't any 'fair use' right for CD/tape/vinyl music in the UK. The closest is that for making recordings of 'broadcasts' (includes cable tv). A phrase similar to 'fair use' is 'fair dealing', which is applicable in general to academic works (and has some new restrictions due to that EU directive).
So, yes, this is/was news, the BPI is basically saying they're waiving their right to sue anyone for what is, legally speaking, an infringement.
And indeed that EU directive has given us a clause prohibiting reverse engineering "the functioning of a computer program".
Ah, one thing occurs to me. The majority of DSL in the UK is 'resold' from BT's infrastructure. As it's their equipment at the DSL/DSLAM level it'll be them that are doing this "give them some extra speed to account for overhead", so you get it no matter what ISP you're using (and no doubt OfCom would frown upon any ISP trying to claim they sell the 'faster' speed when everyone else is honest about it). I wonder if LLU-provided DSL is generally the same ?
Indeed, I'm in the UK on Zen Internet, and when I look at my actual line speed on my DSL router I get told my 1Mbps/256Kbps connection is sync'ing at 1152/288 Kbps.
A cursory check with OpenSSH on my debian box showed you can set the environment variables and gain access to an ssh-agent you "shouldn't" have access to. Although the way I tested it OpenSSH may still have been doing 'something clever' in the background (ssh -a localhost to get a fresh login without contact to the previous ssh-agent, change the "env | grep SSH" variables to those from the previous ssh-agent, try ssh to a remote machine that the ssh-agent is set up for and I got in).
/. poster got confused and tried to make out the article is about a flaw in ssh, it's not. The article is about how Mr. Incompetent Sysadmin can easily configure ssh/ssh-agent/keys/firewalls to enable security holes that wouldn't be there if ssh didn't do all this frightfully clever port forwarding, agent forwarding, and public/private keypair authentication. Take the article as a heads up "If you do X, be careful because it may means someone else can do Y via it". To sum up "Incompetent Systems Administrators May Open Security Holes On Their Systems!".
So, if Mr. Stupid-Admin on IW is doing this tunneling trick, or otherwise simply has his IW ssh-agent set up to allow instant ssh (via key pairs) to D1 and D2, then if he is currently logged into D1, with agent forwarding enabled, and an attacker has compromised that machine D1, then iff D2 allows ssh connections from D1 using the same key as for IW -> D1, the attacker can hop from D1 to D2 (as he can use the compromised ssh-agent/sshd on D1 to back-request the necessary key interaction on IW).
But, still, this is all about incompetent sysadmins. First if there's no reason to allow ssh from D1 to D2 (to Dn in the general case), firewall it off where-ever possible. Secondly who'd be stupid enough to set it up so the IW -> D1 key pair will also authenticate D1 -> D2 ? An incompetent sysadmin, that's how.
Anyway, all this aside, I think the original
Indeed. As soon as you make reporting cause an automatic action then some dickheads will use said reporting specifically to hassle others.
Indeed, or even more precisely, the entire thing is about incompetent systems administrators.
If your DMZ box needs access to patches then sort out the patch server *pushing* them out. Or at the very least grab them on your workstation from the patch server, then push them to the DMZ host from there. Under no circumstances do this double-tunnelling tricks to allow the DMZ host *any* direct access to the internal patch server, even if it's to a single port, for a single daemon, that you think is coded correctly and thus secure.
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
Or better yet, don't allow the DMZ host to initiate *any* connection outbound from itself, if the services present on it don't need to do such, or failing that, disallow it initiating any connection that isn't out the internet-only-facing interface(s).
However, that's still not what the attack is exploiting, and wouldn't prevent the attack.
The 'attack' is taking an (I)Internal (S)erver, an (I)nternal (W)orkstation, and a (D)MZ host. Your firewall/ACLs are set such that IS can't receive, or will reject, any connection from D. However IS will accept connections from IW, and furthermore IW can ssh to D. So, the well-meaning admin of D, using IW, ssh's to D, setting up a tunnel to forward traffic on port Dx on D back to IW, port IWx, and also ssh's from IW to IS, forwarding IWx to a service on IS. Thus you can now connection to (D's) localhost:Dx and end up talking to the service on IS.
At no point is any connection initiated from D outside of itself, as the data is simply passing back through the ssh tunnel from IW to D, and then back further from IW to IS. And, no, you can't firewall D from talking to any but necessary ports on D, as we're assuming root compromise of D and thus all such bets are off.
Now, if someone has compromised D *and* can hijack this tunnel D IW IS they have access to IS.
Of course the real solution to the base problem is to have IS set up in some way to push data out to D, such that IW's user/D's admin doesn't have to play such silly and dangerous games in the first place. Any such 'administrator' setting up what has been described is incompetent.
Now one last thing. The general attack hinges on an attacker's agent Aa being able to make use of the unix domain socket of the administrator's agent, Da. I'm very certain that when I tried this kind of attack on myself way back in 1998 or sooner it plain wasn't possible. If it is now then the (Open, whatever)ssh code has taken a step backwards. Basically some check was done on the origin of the messages on the socket, and if they weren't as expected the request to use the keys in the agent was denied. I think it was along the lines of "is the requesting process a (sub(sub...))child of myself?", presumably by following parent process IDs back up until it finds itself or init. Yes, ok, if the agent spawned any child that spawned a service that was subsequently compromised and not put in a new session group you could probably pull off the attack, but that is unlikely (as any service daemonising itself will end up in a new session group).
Still, for all practical intents and purposes, read-only.
Sure, there's 'write support', if you like replacing a file with one of the exact same length every time. No truncating, no extending. You might possibly be able to change the file length within the bounds of the block size, but I've not tested that.
Yes, so you can transfer files Windows -> Linux still, but not the other way using NTFS.
Personally I just use Samba on my file server which both can access.
Aha! Thankyou for the correction. I was thinking the constant check on any write would be more than a little stupid, I forget that it's MMUs pulling these tricks in the first place.
1) Read /. article /. comments, search for 'PGP'
:).
2) Check the linked-to article. Good, nothing about sending back a 'rejection' to the sender of an unapproved email, which you were going to bitch about on the grounds that it's as bad as spam itself. Remember that you DO harangue anyone running a whitelist anti-spam system that spams *you* when some spammer spoofs your email address in the From field.
3) Have it occur rather quickly to you that this 'key' system already exists, it's called PGP.
4) Look at
5) Find this post.
*applause*. You beat me to it
also btw its every write to a new page that triggers a copy not every single write
I assumed the poster you're replying to was referring to the need to check the reference count on every write, not what you then do if the count was larger than one. That IS a large overhead, given it's for every write, it just gets worse on those writes that turn out to be to a currently shared page.
Indeed, I would say the spirit of the new ToS clauses is "we're now giving you this extra stuff for no charge, on the condition you allow these ads on your pages, anything you do to prevent people showing those adds is against our ToS and we'll terminate service to you, as otherwise you'd be getting the extras entirely free".
The one clause prohibits doing so directly in the LJ style code.
The second clause covers "hey guys, I know the ads are annoying, but you can block them like this...", which amounts to the same end result.
Very much seconded.
... Ah, I see, it's due to the images/javascript loading for ads, or failing to, time to block that then".
It's the primary reason I started using Junkbuster, and long-since switched to AdBlock.
"Why's this page loading so damned slow?
Although having said that I find all animated ads entirely obnoxious. Sure, they're doing exactly what they're designed to do, draw my attention away from the rest of the page, but that's exactly what makes me block them. I don't want my attention drawn away in this manner.
I too initially started blocking ads (at the time with a junkbuster proxy) because many of the ad servers were just too damned slow. This meant that my browser would block waiting for an ad to load, and the actual content of the page would be delayed in loading. Very, very annoying.
Of course any time I see an ad now, given I'm used to them being blocked (with AdBlock these days) I find them annoying to see at all, as they only distract (by design) from the main page, especially if animated in anyway.
And then there's the point that the chances of my actually ever clicking on any ad are so vanishingly small that I'm actually saving the ad servers some amount of bandwidth money that would have been wasted.
Damn, I just used up my moderator points before reading this.
+1 Informative.