Very nice of you. But I figure her English is better than your Russian.
And her Ukrainian may be even better than her Russian.
They are separate languages. Russian was forced on the Ukrainians by the Soviets, just like in the rest of the USSR. I'm sure she does speak Russian, but you cannot assume which is her "native" language.
Currently lots of bandwidth and computer resources are wasted on the human readable part (just, for a second, consider how many bytes of totally pointless commented xml/html fragments are transmitted on the average site, how many brackets, quotes and verbose tagnames the average webpage contains).
Except... DJB has more of a point (heh) since svg is usually gzipped as opposed to plain-text smtp (so bandwidth gains are nil). Even for the more general case of xml transferred of http, you have Transfer-Encoding: gzip.
Show me some numbers on how this encoding saves orders of time in parsing and I'll listen. If all it does is encode tags as sequences of bits, it's just performing a weak form of dictionary compression and doesn't help at all with the real issue of data extraction (indexing specific points in the file). However, I can't find any numbers, nor any information whatsoever about the ebxml you describe after five minutes on google (everything points to "electronic business using XML", even along with terms like "wap" and "soap"). So perhaps ebxml isn't the Next Big Thing.
I read through your post and you give absolutely zero reasons why ebxml would be better than regular text-based xml:
Instead of the verbose tags and the tedious brackets
What a minute, you're reading the XML text yourself or generating XML text from a script? You shouldn't do that. You see, generating XML using standard APIs in the "long term will save you from some headaches."
Ebxml can be parsed very efficiently (after all xml is nothing but a simple tree representation)
After all, text-based XML and ebxml are nothing but simple tree representations.
If you think about what ebxml does (dictionary compression on tags from what you describe), you'll see it saves absolutely no time whatsoever in parsing but merely removes the task of lexing. Lexing (symbol recognition) takes no time at all.
If you construct xml using an api rather than output text to some stream (which in the long term will save you from some headaches), ebxml makes no difference at all.
Except that it's more difficult to "to read, debug and generate from scripts".
If you really want to cut bandwidth, you will note that so much of what we send over the Internet is plain text; therefore, we can ensure that Dave and Virginia go to college if we simply adopt some simple spelling reforms to cut the redundancy of English.
The (old) trick works by sending out spam that generates a click-through when someone opens the email.
Presumably Google is smart enough to check referer logs when charging for adwords. If they don't check referers, a much simpler and more reliable attack is to embed a 1px by 1px iframe in your own high-traffic website.
If it doesn't work on the first go (for whatever reason) you are going to be doing a lot of prowling through less-than-helpful text, line at a time.
Try
make >/dev/null
or
make -s
If you do that, the only output you get is stderr:
ld: warning multiple definitions of symbol _deflate/usr/lib/libz.1.1.3.dylib(deflate.o) definition of _deflate/usr/lib/libz.dylib(deflate.o) definition of _deflate ld: warning multiple definitions of symbol _deflateCopy
which shows you what the problem is. More generally, unix tools are built to be quiet by default when things don't go wrong, and to separate errors from non-errors; compare:
C:\Documents and Settings\Administrator>nmake > nul
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified Stop.
with:
% make make: *** No targets specified and no makefile found. Stop.
Wanted to mention that I was a bit too rabid in my reply there - didn't realize I was replying to you. This is something like the third time I've flamed you on some technical detail without checking the username. I guess you're open to that when you're one of the few people to post technical stuff on Slashdot:)
ISO/IEC 9899:1999 ("C9x") section 5.1.2.2 specifies that the function called at program startup shall be called "main"; furthermore, that function must return int. If you define a function called "main" in a program running on a conforming hosted environment, your function must return int.
The article to which you linked discusses Age of Empires which is a piece of software that runs on top of Windows. If it requires you to be root, then that is unfortunate, just like it would be if the (hypothetical) OS X version of that game required you to be root. But again, saying that a certain windows application is not doing what it should is not the same as saying that the os should be designed different.
Just typed "Age of Empires" into google and it seems this game was written by Microsoft.
If Microsoft incorrectly writes their own games to require administrator privileges, what incentive do independent vendors have to write their applications correctly?
The point of encrypted POP3 or IMAP is not to encrypt the email, but to encrypt the password, which would otherwise pass in the clear.
You'll note that the parent mentioned that CRAM-MD5 is sufficient for protecting passwords.
How CRAM-MD5 works: server generates a random string and sends it to client along with a timestamp. Client takes random string and password and uses them as a key to a keyed hash function to compute the digest of the timestamp. Client then sends digest to server, which performs the same operation and compares the result.
The idea is similar to other digest authentication protocols except that it uses a keyed hash function to hash a known string rather than hashing a concatenation (or XOR or whatever) of the password and the random data with a traditional, non-keyed hash function. Apparently, the keyed MD5 hash provides better cryptographic security, but protocol-wise, the result is the same: only a digest is transmitted and the digest cannot be replayed. The security of the system depends on the non-reversibility of the hash function.
The parent poster makes an excellent point that SSL is rather overkill for POP/IMAP since CRAM-MD5 can protect your password and you gain little encrypting all the traffic as most smtp is clear-text. I've seen smtp servers that require START-TLS for receiving all mail, but these were accidentally misconfigured smtp servers that were not receiving the majority of mail for users. The CRAM-MD5 rfc points out that this still doesn't prevent tcp session hijacking (which ssl does prevent), and one can spoof a server without the PKI ssl implements, but I wouldn't worry about either of these points when reading email.
Which key sequences do you mean? The only key sequence I know of that a screen saver cannot intercept is ctrl-alt-del. If you check the "require password" checkbox, the screen saver runs on a separate desktop from explorer or anything else so alt-tab etc. won't work. Note that these continue to work if the.scr is invoked directly or via the "test" button in the control panel, but not when invoked by winlogon as a screen saver on the screen saver desktop.
It also appears that winlogon will use the same main desktop for the screen saver unless the "password protected" checkbox is checked, which I did not know until I just experimented with it.
Are you trying to intercept ctrl-alt-del? I can't understand why you'd want to do that.
I've also written a GINA (a couple if you count rewrites:) and I don't think you'd be able to fake the screen saver disabling ctrl-alt-del. The GINA controls the dialog that appears when ctrl-alt-del is pressed normally, but it does not control the dialog that appears when one tries to unlock a locked workstation or return from a password-protected screen saver. That dialog is implemented by Windows which has the more serious effect that it's basically not possible to do alternative (non-Windows) authentication for locking a workstation even if alternative authentication is implemented for regular login. For this reason, I disabled Windows' workstation locking in my GINA (I have some ideas on how to create a similar feature, but there hasn't been any demand for it).
Still, I can't understand why you'd want to intercept ctrl-alt-del. If your kids don't know your password, they can't get into the system. The sequence that allows you stop the screen saver is equivalent to a password, so you were already keeping a secret from them - might as well create a Windows password so they can't get into the system if they hit the power switch.
The implicit casting I'm doing in the "key" declaration (from "char" to "WPARAM") takes care of this
Before any pedant points this out, I'm well aware that character constants are integers, not "chars", and that there happens to be no casting involved in this case. Consider it a thinko.
And as I think about it, I'm not sure how Unicode would mess up your program unless you're doing some very strange stuff, but that would seem to be the most relevant difference between 98 and XP. Post your code and we'll fix it:)
Indentation is screwed up, but you get the idea. Tested in win2k and XP pro, works fine.
Perhaps the problem you're having has to do with Unicode. The "wparam" in XP is in UTF-16. Actually, it's a UCS-2 character since you cannot currently input plane1 UTF-16 characters in XP, but this doesn't make a difference unless your password is in Linear-B:) (But it does mean you can discard the high bits.) The implicit casting I'm doing in the "key" declaration (from "char" to "WPARAM") takes care of this, so it might not work if you're storing your password differently.
MySQL client libraries have been included/bundled with PHP for a long time now, and MySQL support was enabled by default.
This was always a bad thing actually. If you actually used the library distributed with php, you'd often get subtle breakage because your server was a different version.
Another thing to note is that MySQL may drop in popularity as PHP 5 increases in popularity. PHP 5 comes bundled with SQLite. SQLite does not require a server but works directly on database files, yet it provides most of the SQL features needed by most projects. SQLite recently added a last_insert_id() function for auto_increment fields; along with that, the only other mysql-specific features I commonly use are the SQL date arithmetic functions.
Working directly on portable database files opens up a lot of possibilities: projects can simply distribute a tarball of php+sql databases and users can just untar it into a web directory to install without creating database users or running a table creation script. This is also great for web hosting as a provider can just say "store your databases in your home directory" and they don't have to worry about managing database users or moving around table files. Users can set up read-only mirrors of a site just by copying files rather than setting up replication to new sql server. This means that database-driven php sites can be mirrored as easily as html-only sites. SQLite can also be useful in this same way for non-php projects: you can create a database application using QT/GTK/WX in C/C++/Python/Perl and simply distribute source or binaries with a traditional installer or package manager. Users no longer have to set up a database server to use a simple database application.
What I find amusing is that they felt it necessary to mention that they are not endorsing an American company. Assuming this was a boilerplate message (which it certainly appears to be), that would indicate more people are worried about requiring technology from an American firm than making the website universally accessible.
1. A program can call "exec" on any file, whether or not it has the execute bit set. The system does not check, so this is not any real protection.
Where the hell are you making this up? This is blatantly false. I've never seen any Unix system where this is true, and I've seen lots of Unix systems.
int main() { execl("./foo", "./foo", NULL); perror("exec"); return 1; } % ls -l foo -rw-rw-r-- 1 xxxxxxxx xxx 11926 Mar 6 16:07 foo %./test exec: Permission denied
I justed tested this on Linux 2.4, FreeBSD-STABLE, OpenBSD 3.4, Solaris 8 and even SunOS 4.1 which is over ten years old.
You can verify for yourself that this check is not in libc's execl but in the kernel.
Now the execute bit isn't end-all protection. I could, for instance, read in the file, parse the ELF sections, load them up and run the code. On Linux, you can do "/lib/ld-linux.so.2 foo" where "foo" is 644 and it will be executed. There are ways to get around chmod -x if you want to but it would be extremely unlikely that you would by accident execute a program marked non-executable.
OpenBSD and BSD/OS have one (bsd_auth) that exec()s small helper programs which implement the actual auth methods.
Indeed, I just wrote a module for this. I needed one OpenBSD system to be able to authenticate users via LDAP. I did not want it to authenticate arbitrary LDAP users but only those who had local accounts.
I had never worked with login.conf modules before. In fact, I didn't know they existed until yesterday. However, it took me exactly one hour to write a login_-ldap module that did exactly what I needed. I already knew my way around the OpenLDAP APIs, so this one hour was exactly the amount of time needed to figure out how this works. I had written a similar PAM module in the past and it took significantly longer to do that.
Someone noted that PAM has the advantage that you can change policy on the fly without restart. This is not exactly true: applications load PAM modules at startup so if you make a change, you have to restart the application.
OpenBSD login.conf works better than this as the authenticators are separate programs: I did not need to restart sshd or anything else. Changes were picked up as I edited/etc/login.conf and copied my program into/usr/libexec/auth. When developing a PAM module, you usually write a separate small program to test it, but I didn't need to do this with login.conf.
There are other advantages as well: since the authenticators are separate programs, they can't screw up actual daemons if the authenticator has a bug. I also encountered some problems with PAM: occasionally one of the pointers in the PAM structure ended up NULL. This would screw up a particular daemon that I wrote since it would run fine for days but then crash when passed this NULL pointer. I don't know if the problem was in PAM itself or in the modules I was using. Once I figured out that this can happen (not documented anywhere, likely a bug), I was able to consider that NULL pointer as a failed authentication. This wouldn't have happened with login.conf: NULL pointer problems are limited to the authenticator and will not screw with the daemon. Basically, daemons use a safer communicaion system with the authentication subsystem.
So I can say that OpenBSD login.conf is more flexible, safer and easier to administer than PAM. There are, however a couple of disadvantages that would turn off some people:
You have to edit a termcap-formatted file. This was not an issue for me, but if you don't, for instance, know what ":tc=" means, you will very easily get confused. Careful reading of man pages solves this. Termcap-formatted files are really the "BSD" way of doing things, so I don't mind this as it's rather consistent.
The system is more flexible, but that's partly because it's easier to write custom authenticators. You can't "stack" modules like in PAM, so I needed to write code to enforce the policy mechanism I needed (users must have local accounts before authenticating via LDAP). With PAM, you would just edit a config file, not write a C program. I don't believe this is too big of a disadvantage as lots of very valid policies are difficult to express in PAM modules. For instance, what if instead of local accounts I required users on this machine to have a particular LDAP attribute? Is there a PAM module that checks for attributes rather than binding? I don't think so, so you'd end up writing one. With both systems, you end up writing a module when you have a policy that can't be expressed with current modules, but that's much easier with login.conf.
Not sure if that's what you had in mind: it still uses SQL syntax to access the database. Alternatives would be something where you express relationships through code. I can't think of any way to do this that is cleaner than a join statement but I'd like to see what you had in mind.
However, sqllite is designed for exactly what you had in mind: embedding within a program you distribute. It supports exactly that subset of sql that I need for common programs and is very easy to use.
Re:Mac68K build-from-scratch in emulation?
on
NetBSD 1.6.2 Released
·
· Score: 3, Interesting
Cross-compiling seems like a hairy mess.
Cross-compiling not so bad.
I did exactly this for a slew of old Macs that I turned into useful machines by putting Linux on them. Compiling a 2.2 series Linux kernel would take a few days on the machines themselves, so I set up a cross-compiler on a fast machine.
The Linux kernel was easy to compile and move over, but userspace things were more difficult to compile as they tried to link to the wrong libraries (or perhaps the problem was that "make install" would never work since the library would end up in/lib on target machine and needed to be configured as such, but it needed to be in/opt/mac-cross/lib on cross compiler machine). Most documentation for setting up cross compilation is aimed at OS/compiler/embedded developers who build mostly static binaries and don't need to compile and link large sources with dependencies like gtk, so I don't know if many people do this.
I don't remember how I solved this (maybe chroot + hard links + copying stuff from target) so it must not have been too difficult. NetBSD has an nice integrated build system for everything, so this should be much easier for you (Linux was a third choice, NetBSD and OpenBSD had problems on those machines).
Go ahead and set up the cross compiler. It will take some reading and tweaking, but you'll save time in the end. I, at least, think it's far more elegant than using an emulator. Good luck.
1. MacOS X has come with bash since 10.0 in/bin/bash. It wasn't the default shell until 10.3.
2. tar will not pick up HFS forks. Resource forks are somewhat more rare in Mac OS X, but they're still there and some programs won't work without them. Finder forks are everywhere in Mac OS X, and while they're not critical, Mac users refused to use a backup system I provided when it did not preserve finder forks.
You can convert HFS resource forks into regular directories/files that will be picked up with tar/rsync/cpio/whatever. Resource forks can be accessed with the syntax "file/rsrc" or "file/..namedFork/rsrc". You can then copy the resource fork into a file called "._file" parallel to "file" and it will be preserved. This is how resource forks are handled on UFS, but it works on UFS and HFS.
So you can do "mv file/..namedFork/rsrc._file" to prepare file for backup by tar. Put it in a script with a "find" command and you can convert an entire filesystem. (Obviously, do your experimentation somewhere where you don't care if you break your file system.)
Aliases are files with zero-length data forks and the alias information in the resource fork. If you preserve resource forks in one of the above manners, you preserve aliases. Otherwise, you just get regular empty files. I don't know how relevant this is for a backup/archival system as aliases usually break when you move them between systems due to differing volume IDs.
Unfortunately, it's not possible to access the finder fork (creator, type) from the command line using standard utilities.
If you want something that also preserves finder forks, it's possible to create, mount and manipulate HFS disk images (.dmg) from the command line using utilities supplied with Mac OS X. The commands you use are hdid, hdiutil and ditto. This is a PITA, but I just found someone who automated it:
http://www.kernelthread.com/mac/apme/archive/
Unfortunately, you can't access dmgs using standard utilities on other platforms, so this method is of limited usefulness. One of the main points of using tar (for me at least) is cross-platform compatibility: I need to access these files on non-Mac OS X systems (like a Solaris box or my NetBSD/SPARC machine, platforms that commercial vendors are unlikely to port to) but I would also prefer to have the metadata preserved when moving between Mac OS X systems. Other reasons to use tar are that (1) tar archives will remain accessible virtually forever due to their ubiquity (whereas an esoteric backup program probably won't have a version for OSes ten years in the future) and (2) tar comes standard with MacOS X, so your backup system will always work (whereas you may have to wait for your backup vendor to release a new version of their program for 10.4, 10.5, etc., assuming the company exists at that time, but if 10.4 introduces some incompatibility in a script I wrote, I can fix that myself in minutes), and the final reason for using standard command-line utilities is (3) flexibility: you can do anything from any kind of incremental schedule to simulating filesystem snapshots, selectively choosing which files to back up, how often and where and automating the entire process so it's completely transparent to your users.
Back in the days of 10.0, I had a long list of problems with Mac OS X that kept me from using it as a serious Unix system. Some of these were relatively minor and esoteric problems that I doubt many others encountered. Amazingly, each one of these except one has been fixed by 10.3. The only remaining issue I have with Mac OS X is that I can't access finder forks using POSIX APIs. If someone could rectify this, that would be really nice:)
Say you're setting up a LOCAL printer, not a network printer
Right, I've worked in this area.
Microsoft provides interfaces to allow one to write a "Network Print Provider" which is a dll that would control printing when you click that "Network printer" option. Unfortunately, it was very poorly designed as it makes all kinds of assumptions that only apply to SMB/Microsoft networking printer sharing and it gives you little control over how to actually send the job to the printer.
So everyone instead uses the other interface meant for local printers. This was originally meant to support new local printer interfaces (USB, firewire, whatever), but is flexible enough that you can actually make network printing work. Unfortunately, it's abysmally documented: there is documentation available but I won't go into how that documentation is not only inadequate but misleading.
As you see, even Microsoft uses the "local" printer interface for supporting new network protocols. That "local" interface is how you set up JetDirect, LPR and IPP printers (there may be other GUIs that set up a printer but they go through the same interfaces as the "local" printer wizard and you can use that wizard directly if you want). In Windows XP, they added some explanatory text to the dialog, but it's still absolutely confusing. I resorted to writing a small program that sets up printers and telling users "download and run this" instead of guiding them through the ridiculously long process. I didn't have to do this for MacOS X, as the instructions for setting up a network printer using the provided interfaces in MacOS X have three steps, compared to fourteen in Windows. I guess CUPS is just as bad as Windows as I tell my Linux users "we support standard LPR, here are the hostnames, now you're on your own" and users with CUPS-based distros have lots of problems (despite being more adept).
There are lots of other things wrong with how Windows deals with printers. It's really a mess held together with twine and there are various places (like the "local" vs. "network" option in the Add Printer Wizard) where this mess is exposed to the end-user. This is unchanged since NT 4 (it was actually worse in 9x). The fact that I can slap together an intuitive GUI for my users ("intuitive" measured by number of phone calls) shows that Microsoft likely doesn't care about this issue.
Since SCO is distributing nmap, Fyodor can refuse to permit it, and revoke their distribution license.
This is absolutely incorrect and disinformative.
The GPL explicitly prohibits this kind of action. From section four:
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
And from section six:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
This means that the GPL explicitly forbids developers from choosing who can use and distribute the software. The only exception given in section nine dealing with patents, copyrights and geographical distribution exceptions.
When Fyodor licensed nmap under the GPL, he gave up certain rights, among those the right to choose who uses the software.
Fyodor cannot "revoke" SCO's right to distribute nmap. He can only claim that SCO is violating the license and thus SCO's right to distribute is revoked.
This is not some technicality, but is rather fundamental the the FSF's idea of "Free software": the most important privilege the GPL attempts to protect is the privilege for anyone to use the software in any way. The license is absolutely clear on this.
In the past, certain developers licensed software with usage restrictions: for instance, one license I've seen said something akin to "anyone may use this software except members of the United States armed forces." The GPL prohibits these kinds of restrictions.
So the only way Fyodor can revoke SCO's right to use and distribute nmap if SCO is violating the license. He can change the licensing new versions but
if SCO is not violating the GPL,
SCO can continue distributing old versions of nmap and Fyodor has no recourse to stop them as the only way the GPL is revokable is in the case of non-compliance. This fact has been used to fork previously GPL'ed software when a company decides to commercialize the software and changes the license: the company still owns the copyright on their code which is part of the fork, but they have no right to say what people can do with their code as long as those actions remain in compliance with the GPL.
I'm surprised to see myself posting on licensing issues. I don't even agree with the all of FSF's ideology, but their license is very clear.
what do i possibly need 256MB/1GHz with a 5.6" screen for?
I doubt you would find a use for it. I would have a hard time using it as a laptop replacement as well.
However, these things are useful for certain types of applications:
Warehouse inventory. Instead of dragging around a laptop on a cart, you can carry this in your hand outfitted with a barcode scanner.
Hotel industry. You'll note that most hotels have electronic locks. These electronic locks are encoded either with a laptop that has an encoder with a serial cable, or with a Pocket PC if the lock company has ported their software. The Pocket PC generally sucks for these things as you need certain drivers for the serial CF card, so only a few Pocket PC models work and they're generally not built for this type of work and are fragile and unreliable. In any case, having the lock pattern generation/administration software on the same machine as the encoder is very useful, especially if your locks are in a wifi zone.
Any other kind of inventory system. I was recently at a large chain supermarket after hours and some employee was checking barcodes in the aisles with a laptop on a cart. Perfect place for this type of machine.
Scientific work. Say you're a geologist in the field. You can carry this around and hook it up to your measuring equipment instead of a larger laptop.
More generally, you would need something like this whenever you have some custom Windows software that you need to take in places where a laptop is unwieldy. This is the case in a number of industries.
Surprisingly enough, this model doesn't have a serial port, which is what you would use for all of these applications. It's much easier to design custom hardware that interfaces over serial rather than USB. So, I don't know what market they're going after.
Slashdot Mirror
And here's what one sounds like.
How about that for the Mozilla STARTUP SOUND!
And her Ukrainian may be even better than her Russian.
They are separate languages. Russian was forced on the Ukrainians by the Soviets, just like in the rest of the USSR. I'm sure she does speak Russian, but you cannot assume which is her "native" language.
Sounds like a modest proposal for reducing Internet traffic.
Except ... DJB has more of a point (heh) since svg is usually gzipped as opposed to plain-text smtp (so bandwidth gains are nil). Even for the more general case of xml transferred of http, you have Transfer-Encoding: gzip.
Show me some numbers on how this encoding saves orders of time in parsing and I'll listen. If all it does is encode tags as sequences of bits, it's just performing a weak form of dictionary compression and doesn't help at all with the real issue of data extraction (indexing specific points in the file). However, I can't find any numbers, nor any information whatsoever about the ebxml you describe after five minutes on google (everything points to "electronic business using XML", even along with terms like "wap" and "soap"). So perhaps ebxml isn't the Next Big Thing.
I read through your post and you give absolutely zero reasons why ebxml would be better than regular text-based xml:
What a minute, you're reading the XML text yourself or generating XML text from a script? You shouldn't do that. You see, generating XML using standard APIs in the "long term will save you from some headaches."
After all, text-based XML and ebxml are nothing but simple tree representations.
If you think about what ebxml does (dictionary compression on tags from what you describe), you'll see it saves absolutely no time whatsoever in parsing but merely removes the task of lexing. Lexing (symbol recognition) takes no time at all.
Except that it's more difficult to "to read, debug and generate from scripts".
If you really want to cut bandwidth, you will note that so much of what we send over the Internet is plain text; therefore, we can ensure that Dave and Virginia go to college if we simply adopt some simple spelling reforms to cut the redundancy of English.
Presumably Google is smart enough to check referer logs when charging for adwords. If they don't check referers, a much simpler and more reliable attack is to embed a 1px by 1px iframe in your own high-traffic website.
Try
orIf you do that, the only output you get is stderr:which shows you what the problem is. More generally, unix tools are built to be quiet by default when things don't go wrong, and to separate errors from non-errors; compare:with:Wanted to mention that I was a bit too rabid in my reply there - didn't realize I was replying to you. This is something like the third time I've flamed you on some technical detail without checking the username. I guess you're open to that when you're one of the few people to post technical stuff on Slashdot :)
That's rather heedless of you: you obfuscate your own email address on Slashdot but not someone else's?
ISO/IEC 9899:1999 ("C9x") section 5.1.2.2 specifies that the function called at program startup shall be called "main"; furthermore, that function must return int. If you define a function called "main" in a program running on a conforming hosted environment, your function must return int.
Your code is undefined. HAND.
Just typed "Age of Empires" into google and it seems this game was written by Microsoft.
If Microsoft incorrectly writes their own games to require administrator privileges, what incentive do independent vendors have to write their applications correctly?
You'll note that the parent mentioned that CRAM-MD5 is sufficient for protecting passwords.
How CRAM-MD5 works: server generates a random string and sends it to client along with a timestamp. Client takes random string and password and uses them as a key to a keyed hash function to compute the digest of the timestamp. Client then sends digest to server, which performs the same operation and compares the result.
The idea is similar to other digest authentication protocols except that it uses a keyed hash function to hash a known string rather than hashing a concatenation (or XOR or whatever) of the password and the random data with a traditional, non-keyed hash function. Apparently, the keyed MD5 hash provides better cryptographic security, but protocol-wise, the result is the same: only a digest is transmitted and the digest cannot be replayed. The security of the system depends on the non-reversibility of the hash function.
The parent poster makes an excellent point that SSL is rather overkill for POP/IMAP since CRAM-MD5 can protect your password and you gain little encrypting all the traffic as most smtp is clear-text. I've seen smtp servers that require START-TLS for receiving all mail, but these were accidentally misconfigured smtp servers that were not receiving the majority of mail for users. The CRAM-MD5 rfc points out that this still doesn't prevent tcp session hijacking (which ssl does prevent), and one can spoof a server without the PKI ssl implements, but I wouldn't worry about either of these points when reading email.
Details in rfc 2195.
It also appears that winlogon will use the same main desktop for the screen saver unless the "password protected" checkbox is checked, which I did not know until I just experimented with it.
Are you trying to intercept ctrl-alt-del? I can't understand why you'd want to do that.
I've also written a GINA (a couple if you count rewrites :) and I don't think you'd be able to fake the screen saver disabling ctrl-alt-del. The GINA controls the dialog that appears when ctrl-alt-del is pressed normally, but it does not control the dialog that appears when one tries to unlock a locked workstation or return from a password-protected screen saver. That dialog is implemented by Windows which has the more serious effect that it's basically not possible to do alternative (non-Windows) authentication for locking a workstation even if alternative authentication is implemented for regular login. For this reason, I disabled Windows' workstation locking in my GINA (I have some ideas on how to create a similar feature, but there hasn't been any demand for it).
Still, I can't understand why you'd want to intercept ctrl-alt-del. If your kids don't know your password, they can't get into the system. The sequence that allows you stop the screen saver is equivalent to a password, so you were already keeping a secret from them - might as well create a Windows password so they can't get into the system if they hit the power switch.
Please do reply, I'm interested.
Before any pedant points this out, I'm well aware that character constants are integers, not "chars", and that there happens to be no casting involved in this case. Consider it a thinko.
And as I think about it, I'm not sure how Unicode would mess up your program unless you're doing some very strange stuff, but that would seem to be the most relevant difference between 98 and XP. Post your code and we'll fix it :)
Works for me:
Indentation is screwed up, but you get the idea. Tested in win2k and XP pro, works fine.Perhaps the problem you're having has to do with Unicode. The "wparam" in XP is in UTF-16. Actually, it's a UCS-2 character since you cannot currently input plane1 UTF-16 characters in XP, but this doesn't make a difference unless your password is in Linear-B :) (But it does mean you can discard the high bits.) The implicit casting I'm doing in the "key" declaration (from "char" to "WPARAM") takes care of this, so it might not work if you're storing your password differently.
Right click, "select all".
That'll be $300. Invoice is in the mail.
This was always a bad thing actually. If you actually used the library distributed with php, you'd often get subtle breakage because your server was a different version.
Another thing to note is that MySQL may drop in popularity as PHP 5 increases in popularity. PHP 5 comes bundled with SQLite. SQLite does not require a server but works directly on database files, yet it provides most of the SQL features needed by most projects. SQLite recently added a last_insert_id() function for auto_increment fields; along with that, the only other mysql-specific features I commonly use are the SQL date arithmetic functions.
Working directly on portable database files opens up a lot of possibilities: projects can simply distribute a tarball of php+sql databases and users can just untar it into a web directory to install without creating database users or running a table creation script. This is also great for web hosting as a provider can just say "store your databases in your home directory" and they don't have to worry about managing database users or moving around table files. Users can set up read-only mirrors of a site just by copying files rather than setting up replication to new sql server. This means that database-driven php sites can be mirrored as easily as html-only sites. SQLite can also be useful in this same way for non-php projects: you can create a database application using QT/GTK/WX in C/C++/Python/Perl and simply distribute source or binaries with a traditional installer or package manager. Users no longer have to set up a database server to use a simple database application.
What I find amusing is that they felt it necessary to mention that they are not endorsing an American company. Assuming this was a boilerplate message (which it certainly appears to be), that would indicate more people are worried about requiring technology from an American firm than making the website universally accessible.
Glad to see they did a bang-up job of supporting such an innovative new feature:
I don't know how I could possibly continue using mutt in the face of such innovation.
Where the hell are you making this up? This is blatantly false. I've never seen any Unix system where this is true, and I've seen lots of Unix systems.
Try it:
I justed tested this on Linux 2.4, FreeBSD-STABLE, OpenBSD 3.4, Solaris 8 and even SunOS 4.1 which is over ten years old. You can verify for yourself that this check is not in libc's execl but in the kernel.
Now the execute bit isn't end-all protection. I could, for instance, read in the file, parse the ELF sections, load them up and run the code. On Linux, you can do "/lib/ld-linux.so.2 foo" where "foo" is 644 and it will be executed. There are ways to get around chmod -x if you want to but it would be extremely unlikely that you would by accident execute a program marked non-executable.
Indeed, I just wrote a module for this. I needed one OpenBSD system to be able to authenticate users via LDAP. I did not want it to authenticate arbitrary LDAP users but only those who had local accounts.
I had never worked with login.conf modules before. In fact, I didn't know they existed until yesterday. However, it took me exactly one hour to write a login_-ldap module that did exactly what I needed. I already knew my way around the OpenLDAP APIs, so this one hour was exactly the amount of time needed to figure out how this works. I had written a similar PAM module in the past and it took significantly longer to do that.
Someone noted that PAM has the advantage that you can change policy on the fly without restart. This is not exactly true: applications load PAM modules at startup so if you make a change, you have to restart the application.
OpenBSD login.conf works better than this as the authenticators are separate programs: I did not need to restart sshd or anything else. Changes were picked up as I edited /etc/login.conf and copied my program into /usr/libexec/auth. When developing a PAM module, you usually write a separate small program to test it, but I didn't need to do this with login.conf.
There are other advantages as well: since the authenticators are separate programs, they can't screw up actual daemons if the authenticator has a bug. I also encountered some problems with PAM: occasionally one of the pointers in the PAM structure ended up NULL. This would screw up a particular daemon that I wrote since it would run fine for days but then crash when passed this NULL pointer. I don't know if the problem was in PAM itself or in the modules I was using. Once I figured out that this can happen (not documented anywhere, likely a bug), I was able to consider that NULL pointer as a failed authentication. This wouldn't have happened with login.conf: NULL pointer problems are limited to the authenticator and will not screw with the daemon. Basically, daemons use a safer communicaion system with the authentication subsystem.
So I can say that OpenBSD login.conf is more flexible, safer and easier to administer than PAM. There are, however a couple of disadvantages that would turn off some people:
Here you go - sqllite.
Not sure if that's what you had in mind: it still uses SQL syntax to access the database. Alternatives would be something where you express relationships through code. I can't think of any way to do this that is cleaner than a join statement but I'd like to see what you had in mind.
However, sqllite is designed for exactly what you had in mind: embedding within a program you distribute. It supports exactly that subset of sql that I need for common programs and is very easy to use.
Cross-compiling not so bad.
I did exactly this for a slew of old Macs that I turned into useful machines by putting Linux on them. Compiling a 2.2 series Linux kernel would take a few days on the machines themselves, so I set up a cross-compiler on a fast machine.
The Linux kernel was easy to compile and move over, but userspace things were more difficult to compile as they tried to link to the wrong libraries (or perhaps the problem was that "make install" would never work since the library would end up in /lib on target machine and needed to be configured as such, but it needed to be in /opt/mac-cross/lib on cross compiler machine). Most documentation for setting up cross compilation is aimed at OS/compiler/embedded developers who build mostly static binaries and don't need to compile and link large sources with dependencies like gtk, so I don't know if many people do this.
I don't remember how I solved this (maybe chroot + hard links + copying stuff from target) so it must not have been too difficult. NetBSD has an nice integrated build system for everything, so this should be much easier for you (Linux was a third choice, NetBSD and OpenBSD had problems on those machines).
Go ahead and set up the cross compiler. It will take some reading and tweaking, but you'll save time in the end. I, at least, think it's far more elegant than using an emulator. Good luck.
2. tar will not pick up HFS forks. Resource forks are somewhat more rare in Mac OS X, but they're still there and some programs won't work without them. Finder forks are everywhere in Mac OS X, and while they're not critical, Mac users refused to use a backup system I provided when it did not preserve finder forks.
You can convert HFS resource forks into regular directories/files that will be picked up with tar/rsync/cpio/whatever. Resource forks can be accessed with the syntax "file/rsrc" or "file/..namedFork/rsrc". You can then copy the resource fork into a file called "._file" parallel to "file" and it will be preserved. This is how resource forks are handled on UFS, but it works on UFS and HFS.
So you can do "mv file/..namedFork/rsrc ._file" to prepare file for backup by tar. Put it in a script with a "find" command and you can convert an entire filesystem. (Obviously, do your experimentation somewhere where you don't care if you break your file system.)
Aliases are files with zero-length data forks and the alias information in the resource fork. If you preserve resource forks in one of the above manners, you preserve aliases. Otherwise, you just get regular empty files. I don't know how relevant this is for a backup/archival system as aliases usually break when you move them between systems due to differing volume IDs.
Unfortunately, it's not possible to access the finder fork (creator, type) from the command line using standard utilities. If you want something that also preserves finder forks, it's possible to create, mount and manipulate HFS disk images (.dmg) from the command line using utilities supplied with Mac OS X. The commands you use are hdid, hdiutil and ditto. This is a PITA, but I just found someone who automated it: http://www.kernelthread.com/mac/apme/archive/
Unfortunately, you can't access dmgs using standard utilities on other platforms, so this method is of limited usefulness. One of the main points of using tar (for me at least) is cross-platform compatibility: I need to access these files on non-Mac OS X systems (like a Solaris box or my NetBSD/SPARC machine, platforms that commercial vendors are unlikely to port to) but I would also prefer to have the metadata preserved when moving between Mac OS X systems. Other reasons to use tar are that (1) tar archives will remain accessible virtually forever due to their ubiquity (whereas an esoteric backup program probably won't have a version for OSes ten years in the future) and (2) tar comes standard with MacOS X, so your backup system will always work (whereas you may have to wait for your backup vendor to release a new version of their program for 10.4, 10.5, etc., assuming the company exists at that time, but if 10.4 introduces some incompatibility in a script I wrote, I can fix that myself in minutes), and the final reason for using standard command-line utilities is (3) flexibility: you can do anything from any kind of incremental schedule to simulating filesystem snapshots, selectively choosing which files to back up, how often and where and automating the entire process so it's completely transparent to your users.
Back in the days of 10.0, I had a long list of problems with Mac OS X that kept me from using it as a serious Unix system. Some of these were relatively minor and esoteric problems that I doubt many others encountered. Amazingly, each one of these except one has been fixed by 10.3. The only remaining issue I have with Mac OS X is that I can't access finder forks using POSIX APIs. If someone could rectify this, that would be really nice :)
Right, I've worked in this area.
Microsoft provides interfaces to allow one to write a "Network Print Provider" which is a dll that would control printing when you click that "Network printer" option. Unfortunately, it was very poorly designed as it makes all kinds of assumptions that only apply to SMB/Microsoft networking printer sharing and it gives you little control over how to actually send the job to the printer.
So everyone instead uses the other interface meant for local printers. This was originally meant to support new local printer interfaces (USB, firewire, whatever), but is flexible enough that you can actually make network printing work. Unfortunately, it's abysmally documented: there is documentation available but I won't go into how that documentation is not only inadequate but misleading.
As you see, even Microsoft uses the "local" printer interface for supporting new network protocols. That "local" interface is how you set up JetDirect, LPR and IPP printers (there may be other GUIs that set up a printer but they go through the same interfaces as the "local" printer wizard and you can use that wizard directly if you want). In Windows XP, they added some explanatory text to the dialog, but it's still absolutely confusing. I resorted to writing a small program that sets up printers and telling users "download and run this" instead of guiding them through the ridiculously long process. I didn't have to do this for MacOS X, as the instructions for setting up a network printer using the provided interfaces in MacOS X have three steps, compared to fourteen in Windows. I guess CUPS is just as bad as Windows as I tell my Linux users "we support standard LPR, here are the hostnames, now you're on your own" and users with CUPS-based distros have lots of problems (despite being more adept).
There are lots of other things wrong with how Windows deals with printers. It's really a mess held together with twine and there are various places (like the "local" vs. "network" option in the Add Printer Wizard) where this mess is exposed to the end-user. This is unchanged since NT 4 (it was actually worse in 9x). The fact that I can slap together an intuitive GUI for my users ("intuitive" measured by number of phone calls) shows that Microsoft likely doesn't care about this issue.
This is absolutely incorrect and disinformative. The GPL explicitly prohibits this kind of action. From section four:
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
And from section six:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
This means that the GPL explicitly forbids developers from choosing who can use and distribute the software. The only exception given in section nine dealing with patents, copyrights and geographical distribution exceptions.
When Fyodor licensed nmap under the GPL, he gave up certain rights, among those the right to choose who uses the software. Fyodor cannot "revoke" SCO's right to distribute nmap. He can only claim that SCO is violating the license and thus SCO's right to distribute is revoked.
This is not some technicality, but is rather fundamental the the FSF's idea of "Free software": the most important privilege the GPL attempts to protect is the privilege for anyone to use the software in any way. The license is absolutely clear on this.
In the past, certain developers licensed software with usage restrictions: for instance, one license I've seen said something akin to "anyone may use this software except members of the United States armed forces." The GPL prohibits these kinds of restrictions.
So the only way Fyodor can revoke SCO's right to use and distribute nmap if SCO is violating the license. He can change the licensing new versions but if SCO is not violating the GPL, SCO can continue distributing old versions of nmap and Fyodor has no recourse to stop them as the only way the GPL is revokable is in the case of non-compliance. This fact has been used to fork previously GPL'ed software when a company decides to commercialize the software and changes the license: the company still owns the copyright on their code which is part of the fork, but they have no right to say what people can do with their code as long as those actions remain in compliance with the GPL.
I'm surprised to see myself posting on licensing issues. I don't even agree with the all of FSF's ideology, but their license is very clear.
I doubt you would find a use for it. I would have a hard time using it as a laptop replacement as well.
However, these things are useful for certain types of applications:
More generally, you would need something like this whenever you have some custom Windows software that you need to take in places where a laptop is unwieldy. This is the case in a number of industries.
Surprisingly enough, this model doesn't have a serial port, which is what you would use for all of these applications. It's much easier to design custom hardware that interfaces over serial rather than USB. So, I don't know what market they're going after.