Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Re:When will MD5 be let to die as hash for passwor (Score 1) 165

This isn't a problem for someone else making a new message from yours, but one where they make the message. Say a contract, given two different texts from the contract they could add some "garbage" data to them to make them have identical signatures. Now this attack would be a little far fetched, as soon as you can produce your copy of the message that hashes the same for the signature, you can prove something fishy is going on, just not what right away.

Comment Re:Intrusion (Score 1) 165

While it is true we don't really know why they're after this (their motivations are what we should be appalled at), in this case it's voluntary. With the Nazi's many of their subjects for those purposes did not have a choice. So at least their methods in this case are better in that regard.

Comment Re:Screws are evil (Score 1) 330

Depending on the virtualization technology involved the router may not need to know. I know with kvm each one has a unique mac address that i've got bridged to the real nic. now it might confuse a switch for a bit when it doesn't know where it is, but so far that hasn't appeared to be much of a problem.

Comment Re:A way to determine beforehand? (Score 1) 415

Off hand i can't think of a tool to do this. However, you could always grab the build from the mozilla servers and run it from your home directory. this would check if your plugins are compatible. of course you should back up ~/.mozilla before you do this. I haven't had that break anything since firefox 2, but it is always possible.

Comment Re:Archaeology & Museum work (Score 1) 31

The interesting part here about fingerprints would be that this could allow for better imaging of them over a much larger range of pressures. Meaning that more accurate results of searches could be done. While that doesn't solve anything new it could make things go much smoother than I've seen in the past. i.e. User puts finger onto glass too hard thinking it'll help and then get frustrated when it doesn't work and keep trying harder when only a mild touch is needed.

Comment Re:HP dv7 (Score 1) 207

Yea I don't have anything myself for thunderbolt but I do see the optical version of it as a very interesting way to electrically isolate something. I mean take a look at the way that professional audio equipment works these days, it's all moved out of the case for noise reasons but they still have to have some kind of connection to the computer that will add some noise. This has the potential of letting you take a nearly standard setup and completely isolate each component from noise without having to make a completely customized motherboard or other interfaces. For actual graphics I'd be wary of the latency myself since you'll be moving from nano seconds (benchmarks I've seen say about 128ns) to several microseconds to milliseconds for latency. That might not seem like a lot but I don't think most current graphics cards would deal with that well. They may however still work incredibly well for GPGPU stuff since if you're doing it right you should be doing more than a few milliseconds of computation on the card. I mean imagine this letting you build a bank of a few hundred cards with a higher efficiency and high capacity power supply.

Comment Re:Stupid (Score 2) 413

Please read mine. I answered your concerns there already. Your concerns about network transparency are fear mongering because you are not actually looking at alternatives. RDP/NX on a single window does exactly the same thing as X11 forwarding, with the possibility of even moving the windows from one display session to another, or even sharing it on multiple sessions at once. As far as nesting goes, wayland already supports it, and has since last year. The features it's added are better ram usage, better hardware accelerated drawing (Yes this is a FEATURE, it isn't used ONLY for wobbly windows and other inane shit like that, it's also used for fonts, scrolling, and all the other stuff that 100% of users in ALL cases do [only exception might be someone ONLY playing videos or other recorded media]).

X11 does not actually do network transparency very well at all due to it's synchronous nature and this cannot be changed without removing backwards compatibility from the protocol. RDP/NX on a single window does do EVERYTHING that X11 over network does, and more. For example, using lossy compression for low bandwidth links to get the larger picture and then sending changes without such compression, lower latency input (since there isn't multiple back and forths acknowledging the input), the ability to detach the window without closing the application, the ability to RECONNECT to an application that's already running, the ability to move an application from one machine to another without closing and reopening it.

How does X11 solve any of those things? It doesn't. It never tried to, it was never intended to. But people do need to do this in some environments, that's why things like RDP and NX were created, and they can and do solve the exact same thing that X11 network transparency provides.

No where in these discussions have you even tried to answer the question of "What does X11 do that NX/RDP doesn't?" If you're only issue is that ssh -X or ssh -Y doesn't work with wayland then you need to actually consider that you're not really concerned with network transparency but just ssh supporting forwarding of the display which is still possible to do, it just hasn't been done YET. And if that's the only issue, then you need to stop spreading FUD about others projects when you're just upset that they aren't mature yet.

Comment Re:Stupid (Score 1) 413

X11 may be network transparent, but the problem is that the large amount of the extensions that have been bolted on to it in the past 20 years are not really network transparent. many of them internally use shared memory and other tricks that cause them to either not work at all, nvidia's glx implementation was[is?] horrible about this in the past.

Now let me ask you something, why can this not be done after the fact? You seem to be misunderstanding that X11 and Wayland are trying to solve the same things, in the case of Wayland what's being done is not the same thing as X11. Wayland is being designed so that the clients are free to build their display in any method they want: X11!, OpenGL, VNC, RDP, NX, Direct3D [the linux open source drivers will do some of 10/11 if support is compiled in], etc. They then tell Wayland where it is to display it, currently i believe either from shared memory or from an opengl texture or something like that. That's all wayland is doing, that's all it's intended to do. There's already a port of Xorg to it to display existing applications, and even work being done to give it network transparency in the correct way. This is by doing the rendering on the remote side on a non-displaying wayland server (which is the way it's being done these days 90% of the time on X11 already) and then transferring that using the "damage" information to send only the changes. This will allow a much nicer way to do both accelerated 3d and 2d operations over a remote link than is usually possible with X11 (again due to the way the binary blobs handle things, nvidia uses a device in /dev to send commands to the card rather than doing it through the X server a lot of times, to get better performance), this prevents it from working very well over a network with some drivers. This would also remove the need to send all the textures, vertex buffer objects, polygons and everything over the remote link to be able to even draw the screen.

Now this also isn't the ONLY way to do it either, because wayland isn't trying to solve this problem and is instead leaving it to others to work on you could even still do this like X11 is doing and send it as commands over the wire, or render it in CPU on the remote side, mesa's new architecture makes this far easier than it has in the past to do all of this stuff.

Now I will admit that I can understand that some of this stuff should have likely been fixed up in Xorg/X11 already (or in a new revision of X altogether), but the thing is, nobody has. It's been a problem for years now and all anybody has done is bolt on partly supported extensions (go look at the state of XRENDER support in all the drivers, it's atrocious. And also the stuff between EXA and XAA doing the same thing but different, but one being newer and theoretically a nicer interface but not being supported very well in some drivers.) and moving things out of the X server into client-space because it seems to be simpler to solve the problem there. One of the reasons that Cairo exists is to make any of the drawing operations transparent to the client regardless of what extensions are supported on the X server. Due to the fact that an extension can't be guaranteed to be supported you need to be able to fall back to some other method for drawing when faced with not having the extension you need. Otherwise this means that you can't run which might be acceptable for some specific application, but for something like a toolkit: Qt, Tk, Gtk, Wx, etc. it's not a good idea to just not work. The thing is, as stated before, nobody has taken the time to move any of this into the X servers, either Xorg, Apple (though i'm not sure they care too much about X11 more than a compatibility layer), *BSD, or anybody else with a stake in things working well on X11.

So what would you do in a new version of X? I would expect you'd drop support for the stuff that's not being used anymore: the fully synchronous calls (already being done to X11 have a look at XCB), the old style font rendering, the old line drawing that doesn't do anti-aliased lines, etc. Now I'd also expect that you'd add the stuff that's new that you want to support: new style font rendering supporting antialiasing and cached glyphs [etc], better line drawing supporting all the curves and things that are used today, likely also gradient drawing and other things cairo gives you, you'd also likely make an api that accelerates pixmap drawing (sometimes you just need to display a png or jpeg or the like), and probably simpler setup for opengl programs since lots of things are moving to that for accelerated rendering already. Now given that things are moving to opengl on more modern cards already, even for 2d, why wouldn't you want to implement the drawing methods in terms of opengl inside the X server? This way it takes advantage of them without the client having to worry about any of the details. Well at this point you've arrived at where Wayland is, but you've got a slightly different architecture that gets you network transparency by doing the drawing calls over the network. This makes it difficult for some compression techniques from being easy to implement (jpeg, color space reductions, etc), but it does speed up some others (font rendering could be done just by sending the text itself with small amounts of overhead). The question then becomes which of these do you prioritize? Is rendered text really taking up that much bandwidth or is it the pixmaps and other things like them?

Given the fact that VNC, RDP, NX and the other remote desktop protocols these days tend to do better than X11 currently for remote display I'd say it's worth investigating using something like them (or one of them directly) for handling the remote display problem.

Now given all of that (again!) I would also agree that having it as a goal is important given that there's productivity for users to be had in supporting it. I will not however being to second guess what that priority is, because I myself have not fully researched how difficult any of the options would be to implement either on top of X or on top of Wayland.

Slashdot Top Deals

There's nothing worse for your business than extra Santa Clauses smoking in the men's room. -- W. Bossert

Working...