Firstly, I wouldn't call this the "Russinovich book." David Solomon is the first author for a reason: he was the sole author of the previous (4.0) edition on which Inside Windows 2000 is very largely based. (Helen Custer wrote the first edition for 3.1.)
More importantly, this book is just the Windows version of the mostly Unix-centric tomes the poster mentioned he didn't want. A look at the table of contents reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.
Actually, Citizen made the PDA that the Rex 6000 is based on. It's called the DataSlim 2 (DS2) and is still available in Japan. Citizen licensed the DS2 to Xircom.
Apparently it is very slow and memory-ineffective when you enter notes on the Rex itself in stead of
on the PC and sync it.
It isn't especially slow when you enter notes and contacts. It does eat your memory faster (probably about 2x) until you sync it. When you sync it, the syncing software does memory defragmentation, so it doesn't wind up being any different.
Simply because you *could* use the gameshark to enable something else that's illegal, doesn't make the shark illegal...
Well, the EULA of most every major game and piece of software these days has terms that prohibit "reverse engineering, decompilation, and disassembly." It's pretty easy to prove that the act of producing cheat codes involves reverse engineering and disassembly. Therefore, GameShark is in violation of the license agreements of all the software they publish cheats for (unless they have a special licensing agreement with every game they hack, which they don't).
What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server?
Plus all users on all clients that use any part of the network infrastructure.
???
Not "any part;" only the path between the client and the server. For instance, right now my computer is plugged into an ethernet jack in the wall. On the other side of this jack is a wire that travels through the walls to a locked room that contains a switch. Lots of other people are plugged into this same switch, i.e., there are lots of other "clients using part of the network infrastructure," but because they aren't on the path between me and the server I'm telnetting to, they can't sniff my traffic or (reasonably) launch a man-in-the-middle attack. If we were all connected by a hub, it would be a different story, but then I'd consider the people I share the hub with to be on my path to the server.
Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties.
What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server? Telnet and rlogin are susceptible to network-level attacks: someone sniffs a password off the wire, or someone launches a man-in-the-middle attack to insert some commands into the telnet stream or something.
If I only telnet over networking infrastructure I trust (e.g., there are secured switches on both ends, I trust that my ISP hasn't been hacked, etc.), then I am safe. All users must authenticate with passwords to gain access. With these holes, anyone can remotely log in as root. Yeah, telnet/rlogin/rsh might not be as secure as ssh, but they're no where near the category of vulnerability that this hole exposes.
The article quotes that "...FTP requires packets to arrive in sequence, and TCP requires a receiving end to acknowledge every packet that arrives, so that dropped packets can be resent..." This is incorrect. TCP has a concept of sliding windows where once a number of packets has been received successfully, the receiver increases the number of packets that can be sent without an ack. This is an exponential number, so if it receives 2 packets successfully, it will then tell the sender that it will take 4 before an ack is needed.
TCP still acknowledges every packet; it just batches acknowledgements as an optimization. An important point, though, is that if you starting dropping packets (or if they arrive out of order) at a moderate rate (could even be a small loss rate, depending on your delay and bandwidth), fast retransmit (introduced in TCP Reno) will cause you to acknowledge every packet.
In contrast, UDP never acknowledges (or disacknowledges) a packet.
You still need some form of flow control or rate limiting, otherwise a large percentage of the UDP packets are going to get dropped.
The whole point of Digital Fountain's erasure encoding scheme is that it doesn't care how many packets get dropped on the floor; a client can reconstruct the original data just as efficiently with whatever packets it receives as if the stream had been sent at an optimal rate to begin with.
Plus, you have the problem of UDP streams stealing bandwidth from TCP streams on a limited bandwidth link.
This is a problem. You want to satisfy the people with the fat pipes, but not destroy all the little pipes and hose people's TCP windows. See my other post for a possible solution.
Quite correct. This protocol does not sound at all TCP friendly [yahoo.com]. It needs some way of dynamically responding to network conditions to be that way.
Well, "this protocol" is just multicast (from a network perspective). Though there have been research attempts to introduce pruning in multicast streams, it is inherent a non-flow controllable transmission protocol. If you take offense to the lack of "TCP friendliness" in multicast, then I suggest you complain to Steve Deering, not Digital Fountain.
Multicast is congestion friendly in that it can inherently seriously reduce bandwidth consumption, but it's obviously not congestion adaptive. I think the easiest (and probably best) way to introduce congestion control in a multicast is to have multiple streams at different rates, e.g., you have five simultaneous multicast webcasts of a Victoria Secret show, and folks can join the mulitcast group with the video quality that best suits the bandwidth and congestion on their pipes. This idea works very well for the Digital Fountain-style software distribution: rather than having a server serving the same stream at 10 different rates, you can have 10 servers streaming their own unsynchronized Tornado encodings, and clients can subscribe to however many their pipes can support. With 10 streams of data coming at you, you can reconstruct the original data ~10 times as fast.
This technology (from the write-up anyway) uses some kind of proprietary technique to re-map the data into another domain and send the information required to reproduce it. It sounds kind of like sending a waveform as a series of Fourier coefficients rather than as actual data samples.
Actually, they
useTornado codes (or a proprietary update thereof), an erasure code. That is, they use forward error correction to encode streaming data or a software distribution over a single (or multiple) client-independent streams of multicast. After a client grabs enough packets, it can reconstruct the source file.
Maybe, but comparing what GetRight et al. do (parallel downloading from FTP mirrors) to how Digital Fountain would achieve the same thing (erasure codes) is like comparing cups and string to IP telephony. Sure, they achieve the same thing, but the comparison is a bit insulting...
With the GetRight solution, 100 people downloading from my FTP mirror = 100 TCP streams worth of bandwidth and CPU consumption. With the Digital Fountain solution, 100 people downloading from my mirror = 1 stream worth of bandwidth and CPU consumption.
A "dossier" solution is something like: C:\LIBS\PACDISP>
Sounds good to me. That's a good solution even in the unix world. In/usr/lib I have some subdirectories like/usr/lib/xmms and/usr/lib/bonobo. But I still have 1013 files in/usr/lib (and that's *after* subtracting symlinks), which is a bit excessive. It would be nice if all my libraries were in a logically-organized directory tree (e.g.,/usr/lib/text-processing/spelling/), but who's going to agree on this directory structure? You also have to tell ld.so about all your new directories. I have the same gripe about/usr/bin (I have 2290 files in/usr/bin), but again, who's going to agree on this directory structure so I don't wind up with a one level deep structure with directories named after applications? And it's a bit annoying to have to update all the PATHs in/etc/profile,/etc/csh.login, et al.
But, then again, maybe all this isn't necessary. When you have libraries named "libksysguardapplet" and "libevolution-importer", they sorta speak for themselves.
It's a bit too strict, really. Often times it won't allow me to install a newer version of a package without --force. I've had this issue on Redhat and SuSE.
Actually, sometimes this is right. You'll occasionally run into a case where a package is not backwards compatible and can't coexist alongside an older version. A conservative rpm is your friend in this case.
I guess I just have a thing for knowing exactly what is on my system. Waste not, want not. I still remember having to carefully pick and choose to get what I wanted on my 1.2MB drive.
I currently have 741 (rpm -qa|wc -l) packages installed on my work computer. And this is a pretty bare setup that I just use for work... no games or frivolities. That's a lot of packages to install by hand, upgrade, and keep track of...
but why can't I just have a nice page saying something like: "you need these packages to [install|use|have sex with] this package"?
The other day, I installed Evolution 1.0. I didn't need a webpage to tell me which dependencies I needed to satisfy; rpm complained for me. After downloading about 20 packages one at a time, by hand, I was able to install Evolution. The "download and install 20 supporting packages" bit is exactly what an automatic tool would have done for me. So why, exactly, was is preferable that I wasted ten minutes of my life downloading by hand? Evolution was a nice case, because all the required rpms were sitting in one place on the Ximian ftp server. When I upgraded all the requisite packages to compile linux 2.4 on a Red Hat 6.1 box a few weeks ago, though, the rpms were spread all over the world (rpmfind didn't have most of them), and it took literally *hours* for me to find and download all required rpms. Tell me again why this is preferable to an automatic tool?
I'm probably too anal retentavie on this issue, but when I look at the filesystem I do not want to be saying "what the hell is that?".
In the halcyon days of DOS software installation that you pine over in your comment, what did you do if some program installed a library called lft321.dll? I presume your reaction was, "What the hell is that?" Or were you appeased because it was safely contained in a c:\games\pacman\libs directory, so you knew it was something pacman required? But then rpm gives you the same information: rpm -q --whatprovides FILE and rpm -q --whatrequires FILE. Instead of your libraries being spread out all over your file system, though, they're centralized. So, for instance, you don't need 20 copies of the same library sitting in various places on your disk, which should appeal to your "waste not" maxim.
I guess I've been burned one too many times by updaters that accidently install older modules over newer ones simply because it didn't "know" better.
rpm doesn't allow you to do this. I'd like to hear an example that disproves this, because I've never encountered this problem in years of using rpm.
Then someone says, "You know, Evolution would work just as well with Courier/Cyrus/whatever as an IMAP backend, and then we wouldn't have to pay for the Exchange server or the Exchange connectors.
What do you do about calendars? Exchange calendars are a wonderful thing in the corporate world: You can see everyone else's schedule (if they permit you), schedule meetings when all participants are free, and send the meeting request to everyone (with integrated RSVPs).
Is there *any* serious non-proprietary server-based calendar protocol in the world? If there is, I'd like to know about it. My mail sits on an IMAP server, my address book on an LDAP server, but my calendar gets clumsily spread around with synchronization...
We use the term "lightweight languages" to describe some of the common features of these new languages. The term "lightweight" refers not to actual functionality, but to the idea that these languages are easy to acquire, learn, and use. Examples that would fall into this category include Perl, Python, Ruby, Scheme (and scsh), and Curl.
They are also often (but not necessarily) dynamic, interpreted, and/or loosely typed.
The whole point of my idea is to reinforce a previous posters comment that expecting users to open a terminal and run configure etc. from a CLI is actually a high barrier of entry for most users who are migrating from Windows. Why should we make it tough on them?
I totally agree in prinicple, but in practice, if you're a person who considers a build system that requires you to type --prefix=/usr/local on a command line (rather than typing/usr/local in a textbox) to be a "high barrier," then you probably have no special need for a build from source and would prefer a precompiled binary.
There is a difference between installing from source and straight binaries? Not really. Source install is a two step process. The first step is to compile binaries. Thats it.
Again, I agree that there is no real difference in principle (except source builds fail and cause problems a lot more than binaries because bulid environments are a lot more variable than dynamic linking environments). However, I think there is a major practical difference in terms of usage. 99% of users install binaries. Personally, when new versions of popular software come out, I almost never install them from source or non-packaged binary--no matter how painless the build process--and I've been using Linux for 5+ years.
This is why so much development effort has been put into creating nice, user friendly graphical binary installers, and why so little effort has been put into more general Tk configure frontends. Development energy can be better spent elsewhere.
Besides, the problem of build failure is a serious one. The other day I compiled an (autoconf-based) application that was supposed to build out of the box on my system. The developer, however, had not tested the application with gcc 3, and I had to make half a dozen changes to the source to get it to compile. What do you propose your graphical newbie-friendly builder does at this point? You're pretty much screwed, because there's no way to recover from "error X on line Y" aside from telling the user that there was an insurmountable failure. Binary installers work much better for newbies, because your installer can detect and report (and possibly fetch and install) missing libraries on which the new application is dependent. Then, with very high probability, the installation will succeed. (At that point, the only stumbling block should be things like the locations of configuration files.)
Why cant we have an equivilent of setup.exe that untars the package and runs./configure && make && make install? The process the user sees would be comparable to an InstallShield installer.
When was the last time an InstallShield installer compiled your new program from source for you based on a couple configuration questions?!!
I think the important difference you're forgetting is that Windows installers are installing binaries, while configure and make are building source code. A better analog in the Linux world is rpm or apt-get. There are very few programs these days that don't come with prebuilt binaries for several Linux configurations. And, no, I don't think rpm/apt-get (graphical, if you like) is much harder than setup.exe (modulo dependency satisfaction in rpm, but I would hardly consider the fact that most Windows programs are distributed with (possibly out of date) versions of a lot of libraries you already have to be advantageous).
The process the user sees would be comparable to an InstallShield installer. Open, ask a few questions, pass the answers onto configure,...
I would argue that one of the functions of configure (aside from detecting hella shit about your build environment) is to "ask a few questions." Just do./configure --help or read the documentation, and it'll tell you about all sorts of "questions" you can answer (--prefix=XXX, --with-option-X, --without-option-X, --with-db=db3, whatever). If you're upset that there aren't any little radio buttons to help you answer these "questions", then, yeah, I'm sorry. It is possible for applications to support graphical configuration; the Linux kernel (make xconfig) illustrates this quite nicely. I think having a Tk frontend to configure is major overkill for nearly all applications, though.
Not a flame fest, but a bit of tension
on
Lightweight Languages
·
· Score: 5, Insightful
I was at the workshop, and while it was mostly congenial, there was definitely a bit of tension between the academics and the "industry" folks (if you could call them that...). Basically, the dichotomy was between PL researchers, who espouse the virtues of Scheme dialects and other well designed but not widely used languages, and the applied folks, namely Simon Cozens (Perl), Dan Sugalski (Perl), and Jeremy Hylton (Python), who implement widely used lightweight languages that aren't as "respectable."
There was a bit of a superior attitude from some of the academics, who feel that languages like Perl and Python reinvent the wheel and neglect the body of academic research by coming up with suboptimal solutions to PL problems that have long since been "solved" in the PL literature. Maybe "frustrated" is a better word than "superior." While I can totally appreciate their point of view, I found myself cringing in embarrassment once or twice when a harangue by one of the academics went a little overboard. There has already been one post on the LL1 mailing list that I feel crossed the line.
The discussion came to a bit of head during the (very interesting) "Worse Is Better" panel (based loosely on the writings of Richard Gabriel), which centered on the question of why the most popular languages aren't the "best" ones.
Like I said, though, it was mostly very congenial. Ultimately, I think each camp took something away from the encounter: both new-found implementation techniques, and a greater knowledge of and interest in the other community. There are some practical issues that the Perl/Python guys have to deal with (e.g., interfacing with legacy languages like C) that aren't really addressed by academics, and I think it was great that these issues were brought to light.
The LL1 website, if anyone is interested, is ll1.mit.edu.
The big complaint of the article is that Google is searching for new types of files, instead of HTML.
The only people who complain about this are obviously the folks using crossed fingers for security. The rest of us love that Google indexes different file types.
I'll never forget the day I first saw a.pdf in Google search result. Not that long ago I saw my first.ps.gz in a search result. I mean, how dope is that!? They're ungzipping the file, and then parsing the postscript! Soon they'll start uniso-ing images, untarring files, unrpming packages,.... You'll be able to search for text and have it found inside the README in an rpm in a Red Hat ISO.
Can't wait until images.google.com starts doing OCR on the pix they index...
Slashdot Mirror
More importantly, this book is just the Windows version of the mostly Unix-centric tomes the poster mentioned he didn't want. A look at the table of contents reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.
Not everyone needs a 206MHz Strong Arm. Some of us simple organizer folk are content with a 4.3MHz 8-bit Z80.
If I only telnet over networking infrastructure I trust (e.g., there are secured switches on both ends, I trust that my ISP hasn't been hacked, etc.), then I am safe. All users must authenticate with passwords to gain access. With these holes, anyone can remotely log in as root. Yeah, telnet/rlogin/rsh might not be as secure as ssh, but they're no where near the category of vulnerability that this hole exposes.
In contrast, UDP never acknowledges (or disacknowledges) a packet.
Multicast is congestion friendly in that it can inherently seriously reduce bandwidth consumption, but it's obviously not congestion adaptive. I think the easiest (and probably best) way to introduce congestion control in a multicast is to have multiple streams at different rates, e.g., you have five simultaneous multicast webcasts of a Victoria Secret show, and folks can join the mulitcast group with the video quality that best suits the bandwidth and congestion on their pipes. This idea works very well for the Digital Fountain-style software distribution: rather than having a server serving the same stream at 10 different rates, you can have 10 servers streaming their own unsynchronized Tornado encodings, and clients can subscribe to however many their pipes can support. With 10 streams of data coming at you, you can reconstruct the original data ~10 times as fast.
With the GetRight solution, 100 people downloading from my FTP mirror = 100 TCP streams worth of bandwidth and CPU consumption. With the Digital Fountain solution, 100 people downloading from my mirror = 1 stream worth of bandwidth and CPU consumption.
But, then again, maybe all this isn't necessary. When you have libraries named "libksysguardapplet" and "libevolution-importer", they sorta speak for themselves.
Is there *any* serious non-proprietary server-based calendar protocol in the world? If there is, I'd like to know about it. My mail sits on an IMAP server, my address book on an LDAP server, but my calendar gets clumsily spread around with synchronization...
This is why so much development effort has been put into creating nice, user friendly graphical binary installers, and why so little effort has been put into more general Tk configure frontends. Development energy can be better spent elsewhere.
Besides, the problem of build failure is a serious one. The other day I compiled an (autoconf-based) application that was supposed to build out of the box on my system. The developer, however, had not tested the application with gcc 3, and I had to make half a dozen changes to the source to get it to compile. What do you propose your graphical newbie-friendly builder does at this point? You're pretty much screwed, because there's no way to recover from "error X on line Y" aside from telling the user that there was an insurmountable failure. Binary installers work much better for newbies, because your installer can detect and report (and possibly fetch and install) missing libraries on which the new application is dependent. Then, with very high probability, the installation will succeed. (At that point, the only stumbling block should be things like the locations of configuration files.)
I think the important difference you're forgetting is that Windows installers are installing binaries, while configure and make are building source code. A better analog in the Linux world is rpm or apt-get. There are very few programs these days that don't come with prebuilt binaries for several Linux configurations. And, no, I don't think rpm/apt-get (graphical, if you like) is much harder than setup.exe (modulo dependency satisfaction in rpm, but I would hardly consider the fact that most Windows programs are distributed with (possibly out of date) versions of a lot of libraries you already have to be advantageous).
I would argue that one of the functions of configure (aside from detecting hella shit about your build environment) is to "ask a few questions." Just doThere was a bit of a superior attitude from some of the academics, who feel that languages like Perl and Python reinvent the wheel and neglect the body of academic research by coming up with suboptimal solutions to PL problems that have long since been "solved" in the PL literature. Maybe "frustrated" is a better word than "superior." While I can totally appreciate their point of view, I found myself cringing in embarrassment once or twice when a harangue by one of the academics went a little overboard. There has already been one post on the LL1 mailing list that I feel crossed the line.
The discussion came to a bit of head during the (very interesting) "Worse Is Better" panel (based loosely on the writings of Richard Gabriel), which centered on the question of why the most popular languages aren't the "best" ones.
Like I said, though, it was mostly very congenial. Ultimately, I think each camp took something away from the encounter: both new-found implementation techniques, and a greater knowledge of and interest in the other community. There are some practical issues that the Perl/Python guys have to deal with (e.g., interfacing with legacy languages like C) that aren't really addressed by academics, and I think it was great that these issues were brought to light.
The LL1 website, if anyone is interested, is ll1.mit.edu.
I'll never forget the day I first saw a .pdf in Google search result. Not that long ago I saw my first .ps.gz in a search result. I mean, how dope is that!? They're ungzipping the file, and then parsing the postscript! Soon they'll start uniso-ing images, untarring files, unrpming packages, .... You'll be able to search for text and have it found inside the README in an rpm in a Red Hat ISO.
Can't wait until images.google.com starts doing OCR on the pix they index...