(no subject)

[torkell]

Seen on a web site distributing a RTSP implementation in source code form:

How to configure and build the code on Windows

To configure the code for Windows, first unpack it on a Unix machine

The justification for this is, apparently, "it's rather hard to imagine anyone doing serious development of networking software without having any access to a Unix machine". I do have access to a unix machine, however that machine happens to be at the university, which is not where I am.

Come on, you unix fanboys need to learn that not everyone uses unix or unix-variants. Would you be happy if I distributed code that compiled on linux, but only if you first unpacked it on a windows box?

Comments

[ralesk.livejournal.com]

Distribute your source in passworded ACE files or something that doesn’t have a unix/linux/bsd program for unpacking :P

I fucking hate people who do things like what you described c.c;

[pewterfish.livejournal.com]

That ... makes no sense to me. Granted, the UNIX networking model may be slightly nicer (I think it's pretty sweet, but I've never touched the Windows networking API, so I can't judge). But ... what the fuck?

If it's a puzzle, I find that WinRAR can handle most archiving formats known to man, including most of the UNIX-specific ones. Your mileage may vary, obviously. Failing that, if it still interests you, shoot it my way.

[torkell]

Well, when you get down to it Winsock is basically bind with some extra bits added, and some internal structures changed (which of course breaks programs that hardcode stuff that's in the headers).

The real reason behind this, however, is they have a shell script to concatenate 3 files together in each of 5 directories. That and they use unix line-endings. It gets better, though. Someone has a site for this giving instructions on how to do this in windows, which involves downloading the gnu tools to basically run the shell script under windows, and do things like use "rm" instead of "del", and "cat a b c > d" instead of "copy a + b + c d".

Oh, and the folder on the original web site that you'd expect to contain a pre-built windows binary (the folder path is "public/binaries/windows" or similar), is empty.

[pewterfish.livejournal.com]

Empty binaries path is ... not good, certainly.

However, UNIX line endings... :-O Oh noes! Why does it surprise you that having done their development on a linux box, they don't bother to make a trivial substitution that any reasonably clueful individual can do by tweaking a setting in their text editor? Additionally, most modern Win32 text editors will make this adjustment automatically.

Exactly why they expect you to concatenate files puzzles me, certainly. Still, the above paragraph demonstrates that you're quite capable of adjusting the script.

Remember: open source developers are not compelled to support any architecture, and those who chose to concentrate on features rather than porting and packaging may end up releasing just for the architecture on which they work. Source code that needs to be adjusted to run on your platform is something of a fact of life: I've had to tweak MacOS or Windows-only source in the past to compile and run on a linux box.

I don't normally go off at people to this kind of degree, but I can't help but notice that you're demonstrating a variant of the very attitude you're complaining about here. OS-elitism is a fact of life, and people cheer for different teams. Get over it, and move on.

[torkell]

The binaries folder did once upon a time contain some executables (I went for a wander round there with the wayback machine), but either they never worked or (more likely, given past experience) the wayback machine has problems archiving binaries.

Oh, and the reason behind concatenating files is apparently so a common section can be used in the makefile. I'm guessing it's done this way because that's how it was done for the unix build (with a magic shell script that detected what headers you had and what system you're running).

Hmm, I think I did go a bit overboard there. I should really get hold of or hack a version of notepad that actually understands unix line endings, as apart from that it's a rather nice quick'n'dirty editor. I suppose there's good reasons as to why each platform (unix and derivatives, windows, and macs - I don't know about others) uses different combinations of CR and LF, but it'd have been nice if they had all agreed on one standard.

I think some of that rant stemmed from my current general anger towards computers, after having my desktop wedge itself in interesting ways (where "interesting" involves the computer refusing to shut down, and an application of the Big Red Button), as well as the previous trials in getting various things to compile. Anyway, I'll attempt to tone down the attitude somewhat. I should really inflict Linux on myself, so I get to rant about things from both points of view.

[pewterfish.livejournal.com]

Fair enough. I've experienced zealotry from many fields, and I try never to put up with it. Though that was, of course, mild (and correctly spelled, which is always nice) ;)

The line-endings thing dates all the way back to the origin of the personal computer, I'm afraid: I don't remember the details of the reason it happened that way. Annoying though, I agree. Converting them can be done in a single line of Perl (and there exist binaries of Perl for Windows, I know that much). Failing that, a decent text editor should be able to do it, as I say: TextPad comes to mind, but there are many more.

Interesting failure modes are fun, certainly. Just the other day, I opened a firefox window (my fifth, admittedly, but still) and my entire GUI black-screened. The machine recovered rather nicely to a shell prompt, but it was ... jarring. Between us, Nick and I have somewhere on the order of ten different Unices in the house, so I'm sure we can match you up with an appropriate one, if you like.

[torkell]

Thanks, I do try to speel stuf corectly :)

My current theory as to this problem that I've got (there's more than one thing going on with the desktop) is that a service/driver (under WinNT drivers are services) to do with SecuRom copy prevention wedges in kernel mode anything that tries to access the CD drives (including getting a listing of My Computer). Exactly what causes the service to start is beyond me, but I've only seen it running wha I've had this problem. I've disabled the service, and am now waiting to see if it does it again.

Anyway, regarding unix or unix-like OS's... I have a ye olde IBM Aptiva here (I think 96MB of ram, 300MHz Pentium clone, about 20GB of disk, onboard or PCI graphics, ISA ethernet, CD drive) as the sacrificial lamb, and enough bandwidth to download Linux ISOs with impunity (Demon recently bumped everyone up to 2 meg uncapped for £25/month). So, what variant of Unix/Linux/BSD would you recommend for that, and any big gotchas as regards installing and running it?

[pewterfish.livejournal.com]

Well, personally I'm a big fan of Slackware. If you know Red Hat, you know Red Hat. If you know Slackware, you know Linux. This is because Slack doesn't include ANY fancy graphical config and so on: you're working in the guts of the system so you can see exactly what goes where.

Ubuntu is often recommended for newbies to linux, but since you've got me and Nick in house as of September, and you're not clueless on the 'internals of the comp-yoo-tar' bit, I'd personally recommend Slackware. Trial by fire, and all that.

[olego.livejournal.com]

Hey, I'm planning (still planning) to make my puzzle run on BOTH Windows AND *nix. (Though I don't know how I'd accomplish it. :-D)

At least to me, Windows has 2 different networking modes.

The first is just like *nix, but worse: it has only a handful of FDs, it doesn't treat files and sockets the same way, etc. All these are the lowercase function names.

But then there are the CamelHump functions, which provide functionality I've never heard in Unix before. Like a function call to accept a connexion, based on the IP. (As opposed to accept(), check IP, and close().) It also provides a nice multi-threaded replacement for select().

But I agree with your frustration. Writing good code means going by standards, and not using platform-specific hacks.

[torkell]

CamelHump? Not heard that term before. But yes, some of the WSA* and mixed-case functions are very nice.

BTW, you can feed socket handles to the Win32 ReadFile* and WriteFile* functions. Come to think of it, there's not much in the way of I/O handles that you can't feed to those. Shame you can't use CreateFile to create and open sockets.

Anyway, I didn't know you were making a puzzle. I shall have to give it a go once it appears, as the last one was very good.