Slashdot Mirror

Go learn the difference between blocks and sectors before you comment.

No, I'm well aware of the difference. I was having one of my temporary memory lapses and couldn't remember the term block. Since I was in a hurry, I used the word "Sector" and hoped no one would notice. Ah well. :-)

Blocks default to 4096 bytes, because this is convenient for the page cache;

That's what I said.

nothing stops you using a different size.

Bzzt. You need to use multiples of 512, otherwise the blocks and sectors won't line up properly.

For example, I have ext3 filesystems at work using 512 byte blocks (so the allocation unit is 512 bytes) on a system with 4096 byte pages.

And? I did say that 4K was normally used because it lines up nicely with the page sizes. If you use a different size for blocks, it will still run through the paging system, regardless.

ReiserFS tail-packing uses left-over space in blocks, and space that cannot be used as blocks.

What is "space that cannot be used as blocks"? Blocks are managed by the Linux Kernel. You can't muck with the block size you chose. (Though there has been some mutterings about making the last few blocks of an odd sized device accessable in Linux as a partial block.)

4K blocks is less efficient, but still works fine (which would not be true if the OS paged the memory to disk for writes, since the block would be accompanied by 12K of garbage.

You forget about read-ahead caching. For sequential I/O, the reading is run through the paging system to make read ahead more efficient. So the OS is *designed* to read (and potentially write depending on your kernel version) more than it needs. So it fills pages as necessary. Pages used for disk I/O are not the same pages used for Swap I/O, as that would create something of a mess.

Since the page is filled with the complete data from that portion of the disk drive, it can page out the correct data to disk. i.e. No 12K of garbage as you propose.

I *don't* know if the page sizes used between the file and swap systems are required to match up.

[info]
[more info]
[more, but older, info]

Reads and writes at the OS level can still be done on a single-sector basis; it's just inefficient, as each sector ends up filling a page in the cache, either with the other 7 sectors needed to make up one page, or with dummy data.

I'm not aware of any APIs that allow you to address a block device in a unit smaller than a block, but it's always possible that such an API has been added to recent kernels. I sincerely doubt you'd want to use direct sector addressing, though, since it would probably screw up the OS's attempts at block level locking.

See my other post with links on how to setup TLS for your mail server, more info on building the web-of-trust, and GPG downloads for your windows friends.

http://yro.slashdot.org/comments.pl?sid=132181&cid =11046941

Also note that the ======== http://link ======== at the end of the parent post has been mangled by Slashdot Submissions Co. and should be fixed before forwarding it on to your friends, or posting anywhere. Broken links have never impressed anybody.

WTF - Here are some links from the link above again. Sorry about the bandwidth wastage but I think it's worth people seeing as practices contained within are sure to benefit us all (in Utopia - yay!)

[--snip-- (abridged) ]

WinPT :: Windows Privacy Tray [sf.net] is a good place to direct your friends still using windows.

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that.
:: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at] your next LUG [debian.org] meeting .

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys .

- - - - - - GPG keys -- The new web. - - - - - - -

[--snip-- (abridged) ]

Does anybody know of a good clearinghouse with information on plugins for a variety of mailers I could send my dad, high school friends, or grandmother to?

Anybody know of a list out there that collects information on how to secure your email, what's it's all about, and general key maintainence issues (for "the everyday net user")?

WinPT :: Windows Privacy Tray is a good place to direct your friends still using windows.

I'd like to be able to say to a friend: "Here's my key. Go to keepitprivate.com and find a plugin for the email software you use. Then next time you send me some email, just be sure to put it in an "envelope" (it just takes one extra click or can be set to happen automatically). You don't even need to lick a stamp! I value your privacy as much as I hope you value mine!"

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that. My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?
Red Hat :: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at your next LUG meeting.

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys.

- - - - - - GPG keys -- The new web. - - - - - - -

"The remotability of X11 on a window by window basis (as opposed to the whole desktop, which is how it's done in Windows) is central to this."
-------
I'm sorry, I have bad news to you (and I hate to say it): Citrix/ICA can do "window by window" remoting already a long time. and Microsoft's RDP (Remote Desktop Protokol) in their latest versions can do it too. Plus, both take less bandwidth than X. And both are snappier than X, with less latency for the user. And both can near-seamlessly print from the application server to the locally atttached printer of the (maybe Thin) Client. And both can detach from a running session and re-attach to it again (even from another client, effectively providing "session migration").. Can X11 do this too? It is a set of features that is absolutely essential in an enterprise environment of fat servers/thin clients. (Yes, I know Citrix and Windows Terminal Servers cost more money than X11 which ships for free on Linux)

But stay comfortable, I have also some good news for ya (and I luv it):

• The current version of NX/NoMachine, a highly efficient, GPL'd X11 compressor, supports this:
• run with the same speed (or faster) and consume the same low bandwidht (or lower) as Citrix/ICA and Microsoft/RDP. Ths will proof to be a pretty big asset for X11 in the future battle for the enterprise desktops.
• tunnel Citrix/ICA and Microsoft/RDP through its own connection. This will enable all NX clients to seemlessly access and bring to their desktops remote Windows sreens at a better speed than vanilla ICA/RDP.
• support access to X11 applicationss from Windows, Mac OS X, Zaurus, iPAQ and mobil phones. This is the start of ubiquitous desktop computing where my own desktop follows me to wherever I roam. I can even access it from booting the latest Knoppix (V3.4)

• And one of the next releases of NX/NoMachine will provide this:
• support the display of single application windows from remote Windows Terminal Servers. This will make Windows --> Linux desktop migration scenarios much smoother -- you can offer a better way of keeping a lifeline back to the MS world for the transitional period where your users still need it for lack of a Linux implementation of a particular software.
• support the de-taching and re-attaching from an X11 application without loosing the session.. This will enable "session migration": stop working in office, go home, kiss baby, have dinner, say goodnight to kids, finish that damn important document for next morning by dialing into your still running desktop session from home.
• support seamless printing from X11 applicaton server to locally attached printer. The benefit is pretty obvious.

Those who don't know about NX by now are missing something really cool and useful.

Hey, and it case you haven't noticed: I said it is GPL! Yes, GPL licensed!! (OK -- NoMachine as the NX inventors have dual-licensed:it to themselves, and they are also building and selling a commercial product on top of the exact same GPL libraries.... So what? Trolltech do this with Qt, Codeweavers do this with WINE, MySQL do this with MySQL and Redhat do this with the Linux kernel. Let NoMachine also pay their own developers.)

Oh, and in case I forgot to mention it: NX is really cool. See also this paper from Linux-Kongress 2003

And tell me what exactly are the bandwidth requirements of X?

Actually, the remote X problems aren't so much the bandwidth (which *is* important) but much more the "roundtrips". Depending on link latency each X protocol "request" by the X application client, that solicits a "reply" from the X server, introduces additional wait cycles. There comes a point where increasinb bandwidth doesn increase speed: you sit there with an empty pipe and waith for roundtrips to finish....

I hate to say it, but Citrix with their ICA, Microsoft with their RDP and Tarantelly with their IAP are all doing a much better job here and use far less bandwidth, making their stuff even work over modem links..

Overall, roundtrips make X feel very sluggish across WAN or low bandwidth links.

This paper gives a few good examples and figurs about plain vanilla X and NX-enabled X:

• a Mozilla start-up alone produces nearly 6.000 round-trips and needs more than 7 minutes to complete over a 9.600 baud modem connection. With the help of NX, the round-trips are boiled down to a few dozen, and a startup may only take 20 seconds over the same modem link!
• a full-screen KDE session transfers 4.1 MByte of data over the wire, if it is run over a vanilla remote X connection. Run it over NX, and the second startup data transfer volume is down to 35 kByte only! You can run KDE sessions over a 9.600 baud modem link and have a responsiveness which is better than TightVNC over a crosslink cable hooking together two boxes only 1 yard apart.
• overall compression/speed gain is 70:1 (on average, across various applications), but can easily achieve 200:1 and more for some applications, like Web browsing.

To me, the GPL'd NX from NoMachine are the saviours for X and remote X connections. Finally someone has created a plugin addon to existing systems, which lets the Unix world compete on par with stuff like Citrix (which, strangely, is now embraced by Redhat). NX is giving a bright future to ubiquitous desktop computing based on Unix. What's best: it can even access Windows sessions (via RDP) with a 2- to 10fold speed increase over plain rdesktop sessions.

I am looking forward to see their session "de-tach and re-attach" feature, as well as their "session migration" (leave office, go home, tease the baby, have dinner, and finish your work via a remote session from home by dialing into the very same destkop that you left back at work). ;-)

To me it seems pretty stupid that Novell/SUSE/LTSP arent using NoMachine's brilliant and highly efficient and GPL'd NX technology.

After all, they could see during last LinuxTag and last Linux-Kongress how well this works even over a modem or ISDN connection with as little as 20-40 kBit/sec.!!

Not only does NX speed up Unix-type X connections with a turbo charger, but also Windows RDP and general VNC sessions.

In the case of X, the avarage gain is a ratio of 70:1 for an office productivity sesson (KDE/destkop, KMail/mailer, Konqueror/filemanager, OpenOffice/wordprocessor and Mozilla/webbrowser all open and in use), when you combine the highest level of compression, with the intelligent cache and roundtrip-elimination NX provides so reliably.

Pretty stupid by their technicians as well as their marketeers, if you ask me.

NX has a few more goodies built-in:

• NX embodies the additional capabilities...
  • ...to connect to Windows Terminal Servers or Windows XP Professional boxes, using the RDP protocol,
  • ...and also to connect to VNC servers, using the RFB protocol.
  In these cases the remote NX proxy uses additional "agents" which speak the RDP or RFB protocols to the remote "foreign" servers. The NX agents translate these other protocols to X primitives, hand them to the remote NX proxy which transfers them down to the local NX client (applying, of course, its built-in compression and caching techniques). NX keeps bitmap updates in their foreign format and translates them into X bitmaps only at X server side, offering, thus, no penalties compared to the client speaking the native protocol. The NX encoding and compression of the resulting X protocol (using its usual algorithms) offer compression ratios ranging between 4:1 and 10:1 in respect to the native RDP or RFB protocol. NX derives its capabilites regarding these foreign protocols from "rdesktop" and "TightVNC" at the remote end, but uses an NX connection between the local and remote proxy.
• NX can share files and printers between the local NX client machine (running the X server) and the remote NX server running applications (that is the X clients)
• NX can tunnel multimedia and sound streams through the connection
• NX can encrypt all traffic using SSH
• NX can display not only remote "fullscreen" desktops, but even individual X applications in "single application window mode" on the local X server display (it makes for cute screenshots to put Konqueror or KMail on an MS Windows XP-based desktop this way)
• NX utilizes the achievements of other OSS developers by plugging their components into its architecture: X11, SSH, Samba, rsync, Xnest, rdesktop, TightVNC, artsd, ESD...
• NX servers don't install an additional daemon, opening an addtional port. NX clients connect to the standard SSH daemon of any given system (usually over port 22) and then start the "nxshell" (effectively starting the NX server and connecting to it). If an administrator cares for securing his SSH server, he implicitely has also cared to a large degree for securing his NX installation.

NX is the starting point for a new understanding of network desktop computing. It makes it possible to connect to your own Desktop, running your own application, using your own data from anywhere in the world even over slow connections like GSM-modems. Not too far from now, in the near future we will "NX-connect" on a peer-to-peer basis to remote applications that run on Linux, Mac OS X, Solaris and Windows application servers somewhere in the world, but are displayed at our local PDA. NX may soon define an X-based web, just like HTTP defined a HTML-based WWW.

>> I'm not able to read the PDF right now...

>> So can anyone address ...

So you are able to read Slashdot responses to your request? Well then you can also read the very good abstract of the mentioned paper for LinuxKongress 2003 here:

http://www.linux-kongress.org/2003/abstracts/#3_7_ 2"

The GPLed work by NoMachine looks very promising. Here are some cross-platform screenshots showing what's possible. Apparently a paper is going to be presented at Linux-Kongress