He's got the same attitude as the Windows guys. He doesn't get that the browser / OS has a main goal of getting out of the way and letting you work.
And thus you demonstrate that you have no clue how most people spend their time on the internet, and that you are clearly not the target market for this software.
That's fine. But, as is so common with Slashdotters, you presume that the tiny minority you are a part of somehow represents the majority of humanity. It's cute, but fantastically naive.
localhost% ssh -X rhost rhost% import -window root shot.png localhost% scp rhost:shot.png . localhost% display shot.png # observe that rhost can see your ENTIRE LOCAL X display
That's not at all what you're claiming. Yes, run an Xclient whose entire purpose is to read the root window, and yes, they'll get it. But *your* claim is that if I run a simple xterm on the remote machine, the attacker will be able to view my root window. Please, explain how that's possible
# type something in the xterm started above
Once again, you're deliberately running a tool designed to attack your X server.
Once again, that's not the same as what you're claiming. Your claim is that by *passively inspecting* traffic on the remote machine, my entire desktop can be viewed.
Again, a hacked Xclient? Yup, that's a problem. Again, run in Xnest if you're that worried.
Since when do X servers forward *all* display activity to an X client?
"But the X client could be hacked!" You say.
Yes, well guess what? The SSH server could be hacked. At which point I think you have far bigger problems, as your credentials are now likely compromised.
Besides, if you're *that* paranoid, just run an embedded X server, and display the X clients there.
You have no idea what you're talking about, do you?
In the world of SSH-tunneled X, you have:
(Local Machine) X Server <- loopback traffic -> SSH tunnel <- loopback traffic -> (Remote Machine) X Client
The X Server forwards keyboard/mouse activity to the X Client, and the X Client responds with graphics data for display on the server. Now, your claim is that if the *remote machine* is compromised, then they can sniff traffic from the X Client, and you're hosed. Fair enough, that's true.
But let's compare to VNC/RDP. In that case, we have:
The client forwards mouse/keyboard activity to the server, and the server sends that data to the underlying OS. The server then takes the results and sends back display information to the client.
But in this case, if the *remote machine* is rooted, it's trivial to create a hacked RDP/VNC server that would forward all keyboard/mouse events, and all display activity, to an eavesdropper. You're *no better or worse off* than with X.
Once again, if your remote box is rooted, remote or local, *you're fucked*.
This is not the case for the other remote display systems that you were originally comparing X to. You obviously need to have a far higher degree of trust in a host that you 'ssh -X' to than VNC or RDP to.
Bullshit! If someone has root access on, say, a Windows box, all they need to do is install a hacked VNC or RDP server to proxy all traffic to them.
In short: if your box is rooted, you're fucked, end of story.
You still haven't explained how that's possible. You would have to intercept the traffic between the X client and ssh. How, precisely, would you do that, short of having root access on the box and some serious kernel-level hackery?
Holistically speaking, Citrix et al completely eclipsed X in terms of network-retargetable display a long time ago and for those times when you want to run an app remotely but don't want to lose the app if your connection dies (which is pretty much all the time) you end up running X over VNC anyway.
Well, smart people run X over NX, which provides wicked performance far eclipsing VNC, integrated encryption (it uses SSH, but it's part of the standard tool), detachable sessions, etc, etc. And that performance is specifically a consequence of NX proxying the X protocol. You'd never be able to achieve that kind of performance using a simple framebuffer-based remote display technology.
Well, as long as Gtk/QT are built supporting *both* protocols by dynamically switching their backend rendering logic, I couldn't care less. In theory, you'd just get X if it was remote, and direct integration with the Wayland server if it was local (not unlike how, today, you get transport over a socket or mitshm).
Now you're going to invoke a conspiracy theory about how the government is all about inefficiency, pork, etc, etc... please... piss off. I reject your claim, so quit trying to make it.
It should never have been. It only cost ~$400 million, which is less than a shuttle launch costs.
Uh, if you launched a whole new telescope, you'd have to launch it in *something*.
So are you saying the $400M for a whole new platform, plus launch costs, is less than a servicing mission? If so, you might want to tell NASA. Given the shoestring budget they run on, you'd think they'd want to save their pennies wherever they could.
here in Winnipeg Manitoba: we dip down as low as -42 degrees.
Yeah, here in Edmonton we say that, too. But you and I both know those reflect unusual cold snaps, not the norm.
The reality is, an average winter day is in the minus 20s, and you can easily get by without gloves at all, so long as you have a decent winter jacket that has, like, pockets. 'course, if you plan to manipulate a touchscreen for even a little while, a pair of gloves isn't a bad idea, but even then, unless it's for prolonged periods, you don't need anything thick or bulky.
Re:LISP a bad choice as a starter language.
on
Land of Lisp
·
· Score: 1
Indeed. If you want a clean, readable functional language, you're much better with something like Haskell (assuming you don't write Haskell like an academic... seriously, *WTF* is with all these single character variable names? Yes, Haskell looks like a system of equations, but it's still a fucking programming language, people).
But no telescope since Hubble has been designed for manned servicing because it's proven cheaper to launch a new one than to send astronauts there.
If that were true, Hubble would never ever have been serviced, as it would be "cheaper to launch a new one". And yet it has been, repeatedly. Not only to fix the original mirror defect, but to install whole new equipment (like the ACS).
What does that have to do with monetary policy? The cost of gasoline is driven largely by supply/demand curves, production rates, and collusion by multinationals.
Your claim is that something *worse* than hyperinflation is coming, thanks to choices in US domestic monetary policy. That's a pretty bold claim, and the rise in gas prices is a) entirely tangential, and b) *still* didn't result in the kind of dogs-and-cats-living-together hellscape that you seem to be predicting.
Show me an actual, professional economist worried about these things, and I might take it seriously. Some random paranoid blogger or republican sock puppet here on Slashdot? Yeah, you'll forgive me if I remain skeptical.
Because any potential inflation due to dollar devaluation will be counteracted by massive deflationary pressures due to an unemployed workforce, employers cutting back on budgets and salaries, etc, etc. There's a reason inflation has been tiny to non-existent, despite the "hyperinflation is COMING!!!" chicken littles out there (yourself included).
If I'm in the market for a smartphone, and I don't choose the iPhone, lockdown is likely a major factor for the decision
Hint: You do not represent the majority of the consumer public. I know, that's hard to believe, 'cuz you're so important and awesome. But it's true.
Now, if you're wondering why this is relevant: carriers aren't working to satisfy *you*. They're working to satisfy Joe Public. Joe Public doesn't understand open versus closed. Hell, they've probably never heard of jailbreaking, or "rooting", as the Fandroids like to call it. So to Joe Public, openness is not, in fact, "one of the major things Android has going for it", 'cuz if you pointed that out to them, they'd have no fucking idea what you were even talking about.
This isn't even closing the door after the horse has bolted (data that's been sold, is sold, any it ain't coming back)
Except the UIDs aren't *data*, per se. While it does allow the receiver of the data to track actions against individual users, which is bad, it doesn't grant them access to private profile data.
That doesn't make this excusable, as individual tracking is bad enough (although it can be just as easily achieved with simple cookies). But it's no massive privacy breach.
Slashdot Mirror
He's got the same attitude as the Windows guys. He doesn't get that the browser / OS has a main goal of getting out of the way and letting you work.
And thus you demonstrate that you have no clue how most people spend their time on the internet, and that you are clearly not the target market for this software.
That's fine. But, as is so common with Slashdotters, you presume that the tiny minority you are a part of somehow represents the majority of humanity. It's cute, but fantastically naive.
So, this isn't considered to be "selective breeding" why now?
If you've been hoping to breed fish by throwing fish toxin in the water, trust me... you're doing it wrong.
localhost% ssh -X rhost
rhost% import -window root shot.png
localhost% scp rhost:shot.png .
localhost% display shot.png
# observe that rhost can see your ENTIRE LOCAL X display
That's not at all what you're claiming. Yes, run an Xclient whose entire purpose is to read the root window, and yes, they'll get it. But *your* claim is that if I run a simple xterm on the remote machine, the attacker will be able to view my root window. Please, explain how that's possible
# type something in the xterm started above
Once again, you're deliberately running a tool designed to attack your X server.
Once again, that's not the same as what you're claiming. Your claim is that by *passively inspecting* traffic on the remote machine, my entire desktop can be viewed.
Again, a hacked Xclient? Yup, that's a problem. Again, run in Xnest if you're that worried.
Damn right. UA detection is a hack, plain and simple. CSS is the way this should've always been done.
Since when do X servers forward *all* display activity to an X client?
"But the X client could be hacked!" You say.
Yes, well guess what? The SSH server could be hacked. At which point I think you have far bigger problems, as your credentials are now likely compromised.
Besides, if you're *that* paranoid, just run an embedded X server, and display the X clients there.
You have no idea what you're talking about, do you?
In the world of SSH-tunneled X, you have:
(Local Machine) X Server <- loopback traffic -> SSH tunnel <- loopback traffic -> (Remote Machine) X Client
The X Server forwards keyboard/mouse activity to the X Client, and the X Client responds with graphics data for display on the server. Now, your claim is that if the *remote machine* is compromised, then they can sniff traffic from the X Client, and you're hosed. Fair enough, that's true.
But let's compare to VNC/RDP. In that case, we have:
(Local Machine) RDP/VNC Client <- loopback traffic -> SSH Tunnel <- loopback traffic -> (Remote Machine) RDP/VNC Server <----> Underlying OS
The client forwards mouse/keyboard activity to the server, and the server sends that data to the underlying OS. The server then takes the results and sends back display information to the client.
But in this case, if the *remote machine* is rooted, it's trivial to create a hacked RDP/VNC server that would forward all keyboard/mouse events, and all display activity, to an eavesdropper. You're *no better or worse off* than with X.
Once again, if your remote box is rooted, remote or local, *you're fucked*.
This is not the case for the other remote display systems that you were originally comparing X to. You obviously need to have a far higher degree of trust in a host that you 'ssh -X' to than VNC or RDP to.
Bullshit! If someone has root access on, say, a Windows box, all they need to do is install a hacked VNC or RDP server to proxy all traffic to them.
In short: if your box is rooted, you're fucked, end of story.
You still haven't explained how that's possible. You would have to intercept the traffic between the X client and ssh. How, precisely, would you do that, short of having root access on the box and some serious kernel-level hackery?
Well, then please explain. How can a *remote* host sniff my keystrokes and snapshot my local X display if the protocol itself is encrypted end-to-end?
Holistically speaking, Citrix et al completely eclipsed X in terms of network-retargetable display a long time ago and for those times when you want to run an app remotely but don't want to lose the app if your connection dies (which is pretty much all the time) you end up running X over VNC anyway.
Well, smart people run X over NX, which provides wicked performance far eclipsing VNC, integrated encryption (it uses SSH, but it's part of the standard tool), detachable sessions, etc, etc. And that performance is specifically a consequence of NX proxying the X protocol. You'd never be able to achieve that kind of performance using a simple framebuffer-based remote display technology.
Well, as long as Gtk/QT are built supporting *both* protocols by dynamically switching their backend rendering logic, I couldn't care less. In theory, you'd just get X if it was remote, and direct integration with the Wayland server if it was local (not unlike how, today, you get transport over a socket or mitshm).
Someone's never heard of "ssh -X"...
Why?
Now you're going to invoke a conspiracy theory about how the government is all about inefficiency, pork, etc, etc... please... piss off. I reject your claim, so quit trying to make it.
It should never have been. It only cost ~$400 million, which is less than a shuttle launch costs.
Uh, if you launched a whole new telescope, you'd have to launch it in *something*.
So are you saying the $400M for a whole new platform, plus launch costs, is less than a servicing mission? If so, you might want to tell NASA. Given the shoestring budget they run on, you'd think they'd want to save their pennies wherever they could.
it would cost about the same to launch a whole new Hubble, with ACS on board, that it cost to service the one on orbit
Again, if that were true, *they would have*.
The latter carried less risk, I guess.
Ah, I see, so in your world, risk has no cost?
here in Winnipeg Manitoba: we dip down as low as -42 degrees.
Yeah, here in Edmonton we say that, too. But you and I both know those reflect unusual cold snaps, not the norm.
The reality is, an average winter day is in the minus 20s, and you can easily get by without gloves at all, so long as you have a decent winter jacket that has, like, pockets. 'course, if you plan to manipulate a touchscreen for even a little while, a pair of gloves isn't a bad idea, but even then, unless it's for prolonged periods, you don't need anything thick or bulky.
Indeed. If you want a clean, readable functional language, you're much better with something like Haskell (assuming you don't write Haskell like an academic... seriously, *WTF* is with all these single character variable names? Yes, Haskell looks like a system of equations, but it's still a fucking programming language, people).
But no telescope since Hubble has been designed for manned servicing because it's proven cheaper to launch a new one than to send astronauts there.
If that were true, Hubble would never ever have been serviced, as it would be "cheaper to launch a new one". And yet it has been, repeatedly. Not only to fix the original mirror defect, but to install whole new equipment (like the ACS).
What does that have to do with monetary policy? The cost of gasoline is driven largely by supply/demand curves, production rates, and collusion by multinationals.
Your claim is that something *worse* than hyperinflation is coming, thanks to choices in US domestic monetary policy. That's a pretty bold claim, and the rise in gas prices is a) entirely tangential, and b) *still* didn't result in the kind of dogs-and-cats-living-together hellscape that you seem to be predicting.
I repeat: chicken littles.
It hasn't happened yet, BUT IT'S GONNA I SWEAR!
Please.
Show me an actual, professional economist worried about these things, and I might take it seriously. Some random paranoid blogger or republican sock puppet here on Slashdot? Yeah, you'll forgive me if I remain skeptical.
Because any potential inflation due to dollar devaluation will be counteracted by massive deflationary pressures due to an unemployed workforce, employers cutting back on budgets and salaries, etc, etc. There's a reason inflation has been tiny to non-existent, despite the "hyperinflation is COMING!!!" chicken littles out there (yourself included).
Republican preference has been consistently underrepresented in polls for as long as I remember
So I suppose you have evidence to back up this rather bold assertion?
No?
Oh. Well, I'm sure we should all believe you, then...
If I'm in the market for a smartphone, and I don't choose the iPhone, lockdown is likely a major factor for the decision
Hint: You do not represent the majority of the consumer public. I know, that's hard to believe, 'cuz you're so important and awesome. But it's true.
Now, if you're wondering why this is relevant: carriers aren't working to satisfy *you*. They're working to satisfy Joe Public. Joe Public doesn't understand open versus closed. Hell, they've probably never heard of jailbreaking, or "rooting", as the Fandroids like to call it. So to Joe Public, openness is not, in fact, "one of the major things Android has going for it", 'cuz if you pointed that out to them, they'd have no fucking idea what you were even talking about.
This isn't even closing the door after the horse has bolted (data that's been sold, is sold, any it ain't coming back)
Except the UIDs aren't *data*, per se. While it does allow the receiver of the data to track actions against individual users, which is bad, it doesn't grant them access to private profile data.
That doesn't make this excusable, as individual tracking is bad enough (although it can be just as easily achieved with simple cookies). But it's no massive privacy breach.
What you describe is what Adblock Plus does.
Of course that's what I'm describing, as I'm describing an ad blocker.
But by then, we're getting into the practice of blocking individual ad servers.
Err... so?
Your original question was:
I gave you an answer. Why are you still replying if you don't have a rebuttal?