Re: sorting in C
On Fri, 14 Jun 2002, David Schultz wrote: Thus spake echo dev [EMAIL PROTECTED]: I am pooling in as many different ways of sorting data in C i can anyone have a fav??? If anyone can give me some ideas on the best way to sort data in C would be helpful.. Thanks I've always been partial to bogosort. Hey, don't be _that_ mean to a poor Hotmail user -- maybe he got that address before W2K, layers of Local Director and Passport. OTOH, asking things like that here still deserves some mockery... -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: if_strip for FreeBSD?
On Tue, 14 Aug 2001, Devin Butterfield wrote: Some All versions of the metricom modems would allow point to point communications when they weren't on the merticom net. I don't know if this driver is for one of these or not, but it might not be a bad thing to do if so. I'll be there will be a lot of cheap modems on the market soon. Sierra evidentally got stiffed for $10M in inventory of these modems. They should be appearing on the surplus market soon... Exactly. This is the reason for my interest. I have a couple of the new 128Kbs radios (the ricochet GS and GT models) and they have a different MAC address format then the older radios that the if_strip driver was originally written for. The difference is only this: Older radio MAC format: - Newer radio MAC format: XX-- or XXX-- So in addition to porting the basic driver to freebsd, it would be smart to add code to accommodate the newer radios. Linux driver changes and formats used are at http://phobos.illtel.denver.co.us/~abelits/metricom/ Oh, and the new radios work in peer-to-peer mode just fine. You can either use them like regular modems and just dial the MAC address of the other modem and establish a ppp link, or they can be used in Starmode (which is what if_strip is for), allowing you to use them like wireless ethernet cards. Exactly. -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Sun, 24 Dec 2000, Warner Losh wrote: : No. This issue was beaten to death multiple times, large amount of : software was created based on this, and its legality is absolutely : certain by now. No. You are wrong. The fact that large amounts of software has been created is irrelevant. The GPL has never been adjudicated. That is a fact. There is no legal precidence for any interpretation of its terms and conditions as written. Until such time as it is adjudicated, it is in doubt. Everything is in doubt. Even the fact that I haven't killed you isn't proven. And everyone can be sued for anything, even if it is perfectly legal. That in no way negates the fact that tons of software coexist with GPL'ed one, and it's accepted practice -- one that even lawyers and judges have to respect. Like you've said, this had been beaten to death many times and I am quite sure of my facts. I have consulted with atterneys investigating the possibility of using Linux and the GPL of the kernel was a deal killer. It was too legally risky because of the multitude of authors of Linux and the possible interpretations of the GPL. That is the big reason why Linus' pronouncement on the issue isn't necessarily legally firm ground. Any one of those authors could challenge someone's non-release of driver source and have legal standing to bring the suit. Unless you get all the authors to agree to that, and the matter will remain risky. Your attorneys are stupid. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Mon, 25 Dec 2000, Warner Losh wrote: Date: Mon, 25 Dec 2000 11:32:03 -0700 From: Warner Losh [EMAIL PROTECTED] To: Alex Belits [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FreeBSD vs Linux, Solaris, and NT In message [EMAIL PROTECTED] Alex Belits writes: : Your attorneys are stupid. Are they now? The GPL was designed to force companies to release sources. The FSF put a lot of time and effort into it so that they could force people to give back mods to gcc and the like. ...but RMS' ones are smart, so GPL/LGPL define as strrictly as possible in a vague world of software, what is "infected" by it and what is not. -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Sun, 24 Dec 2000, Warner Losh wrote: One could argue that adding a driver is a derived work. You are modifying tables in the kernel with references to your device, and the rest comes in under the contamination theory. Until the matter has been properly adjudicated, you cannot say with certainty that your interpretation is correct. : That : means, if you use GPL'ed software in such a device, you have to provide : source for every line of code, and perhaps schematics or gerbers for the : circuits and VHDL for your ASICs as well. : : This is simply not true -- unless your hardware is the result of : modification of GPL'ed program, something that I don't expect to see any : soon, as so far no hardware ever was GPL'ed in the first place. That is your interpretation. Other lawyers disagree with that interpretation. No. This issue was beaten to death multiple times, large amount of software was created based on this, and its legality is absolutely certain by now. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Sun, 24 Dec 2000, Wes Peters wrote: To be pedantic, you only need to provide source for works derived from GPL'd software which in this case means the kernel propper. User land applications and device drivers may be shipped in binary-only form because they are separate works, even when distributed in aggregation with GPL'd software. That depends on the type of "aggregation". If you produce a single-purpose device, like an "internet radio", the entire device has a single purpose, therefore every part of the device is "derived from" every other part. WTF are you talking about? Derived work is the result of modification of the original, not just something dependent on its functionality. That means, if you use GPL'ed software in such a device, you have to provide source for every line of code, and perhaps schematics or gerbers for the circuits and VHDL for your ASICs as well. This is simply not true -- unless your hardware is the result of modification of GPL'ed program, something that I don't expect to see any soon, as so far no hardware ever was GPL'ed in the first place. Doesn't that just make you want to run out and stuff Linux in your multi- million development dollar routing switch now? No, it just makes me wonder, what is the purpose of those ridiculous claims. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGPIPE in multithread http server.
On Wed, 22 Nov 2000, Nicolai Petri wrote: I hope someone can help me with this issue.. When the application recieves a SIGPIPE the thread hangs hard.. What is the correct thing to do when a socket is closed by the remote end ?? When application receives SIGPIPE the correct thing to do is nothing unless you have only one socket or pipe in the whole process -- and even then you shouldn't manipulate data used by the rest of program from inside the signal handler -- ignore the signal ot just set some flag from inside the handler. You can use this flag if it helps you to check if there is any socket that just got closed, however real test for closed socket while you are writing in it is failed write()/writev()/send()/... -- whatever you use to send the data to the other end. Of course, you should also check for empty read() result to see if the socket was closed while you was reading the request. When connection is closed on the other end you must close() it, and consider whatever was sent there to be lost. -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded tcp-server or non-blocking ?
On Thu, 16 Nov 2000, Nicolai Petri wrote: What's the best approach for a simple web-server(never more the 10 clients) ? Is it using pthread and a thread per connection . Or to make a non-blocking single thread server. Can people show me some simple examples of the 2 techniques ? And what's the pro's and con's for the 2 methods ??? I would prefer one process without nonblocking i/o, as multithreaded program easily becomes hard to manage if you have any more or less complex data model. However even apache-style multiple processes will work, and will be even simplier than either -- the disadvantage is only that it will have to keep all processes independent, so some kinds of processing will be hard to implement. I wrote my own HTTP server (fhttpd) that combines nonblocking main process and multiple backend modules processes that can be blocking or nonblocking -- it's possible that what you are trying to accomplish can be done in fhttpd module without writing a full-blown server. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: compiling X apps
On Thu, 16 Nov 2000, Jamie Heckford wrote: Very sorry for posting such a dumb question, but since I cvs'upd something weird seems to have happened. I am using this to compile my X app (which just uses Xlib.h at the mo) gcc -L/usr/X11R6/include -o test test.cc but it cannot locate Xlib.h?!! Any suggestions? 1. man xmkmf 2. -I /usr/X11R6/include -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Viruses are ok, but monkeys are becoming a problem
Can monkeys' owners keep them from posting to lists? Please? On Thu, 2 Nov 2000, Peter Wagner wrote: Date: Thu, 2 Nov 2000 09:34:46 - From: Peter Wagner [EMAIL PROTECTED] To: FreeBSD Hackers List [EMAIL PROTECTED] Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET PICTURES.. ...and infinite number of monkeys responded: From [EMAIL PROTECTED] Thu Nov 2 00:02:52 2000 Date: Thu, 2 Nov 2000 09:41:32 +0200 (EET) From: [EMAIL PROTECTED] To: Peter Wagner [EMAIL PROTECTED] Cc: FreeBSD Hackers List [EMAIL PROTECTED] Subject: VIRUS WARNING WARNING! This mail is generated automatically by virus-scanning software. There was virus found in one or more attachment in e-mail sent by: Peter Wagner [EMAIL PROTECTED] at date: Thu, 2 Nov 2000 09:34:46 - , with subject "US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)=". There is list of infected files: Found virus "VBS/LoveLetter.worm" in DOMEO.JPG.vbs Please clean files and resend Your message, Your message was dropped. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From [EMAIL PROTECTED] Thu Nov 2 00:03:05 2000 Date: Thu, 2 Nov 2000 01:41:59 -0600 From: Nemx Power Tools for MS Exchange Server_US-EA-GTWY-7_0 [EMAIL PROTECTED] To: FreeBSD List [EMAIL PROTECTED] Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient From: Peter Wagner [SMTP:[EMAIL PROTECTED]] To: Date: Thu, Nov 02 2000, 3:34:51 AM Subject:US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= The message contained 1 virus(es): domeo.jpg.vbs infected with the VBS/LoveLetter_based@mm virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From [EMAIL PROTECTED] Thu Nov 2 00:03:16 2000 Date: Thu, 2 Nov 2000 02:43:36 -0800 From: [EMAIL PROTECTED] To: FreeBSD List [EMAIL PROTECTED] Subject: Report to Recipient(s) Incident Information:- Originator:[EMAIL PROTECTED] Recipients:FreeBSD List [EMAIL PROTECTED] Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= WARNING: The file DOMEO.JPG.vbs you received was infected with the VBS/LoveLetter@MM virus. The file attachment was not successfully cleaned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From [EMAIL PROTECTED] Thu Nov 2 00:03:25 2000 Date: Thu, 2 Nov 2000 08:43:08 +0100 (MET) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Virus Alert Have detected a virus (VBS_LOVELETTR.AS) in your mail traffic on 11/02/2000 08:43:04 with an action move. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From [EMAIL PROTECTED] Thu Nov 2 00:03:33 2000 Date: Thu, 2 Nov 2000 02:43:25 -0500 From: Nemx Power Tools for MS Exchange Server_US-BB-GTWY-3_0 [EMAIL PROTECTED] To: FreeBSD List [EMAIL PROTECTED] Subject: Virus Notification: A virus has been detected in a message in whi ch you where a recipient From: Peter Wagner [SMTP:[EMAIL PROTECTED]] To: Date: Thu, Nov 02 2000, 4:34:51 AM Subject:US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= The message contained 1 virus(es): domeo.jpg.vbs infected with the VBS/LoveLetter_based@mm virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From [EMAIL PROTECTED] Thu Nov 2 00:03:47 2000 Date: Thu, 2 Nov 2000 08:43:56 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ALERTE: VIRUS DETECTE DANS UN MESSAGE ENVOYE PAR [EMAIL PROTECTED] A L E R T E V I R U S Notre système de détection automatique anti-virus a détecté un virus dans un message qui vous a été envoyé par Peter Wagner [EMAIL PROTECTED]. La distribution de ce message a été stoppée. Veuillez vous rapprocher de l'émetteur Peter Wagner [EMAIL PROTECTED] pour régler avec lui le problème. *** V I R U S A L E R T Our anti-virus system has detected a virus in an email sent by Peter Wagner [EMAIL PROTECTED]. We have stopped the delivery of this email. We
Re: Time to close the list?
On Thu, 2 Nov 2000, Mike Silbersack wrote: Just having the list ensure that it was in the To: or Cc: header would be sufficient in this case. Such a change would block relay spam as well. Some places with not-so-nice connectivity to the rest of the Internet use local lists to distribute this list among users -- this is why there are messages with no to:/cc: [EMAIL PROTECTED] in the first place. And it will do nothing for autoresponders because autoresponder may happen to be subscribed directly just like anything else. So, real solutions are: 1. configure all autoresponders to never send anything with Precedence: bulk in the header, 2. close the list, as it was proposed. Considering that "offenders" are running their scanners as root, or even on Windows, first solution seems to be impossible to achieve. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ILOVEYOU
On Thu, 4 May 2000, Matthew Dillon wrote: :Lloyd Rennie VBCnet GB Ltd [EMAIL PROTECTED] The 'virus' is the warning message itself, silly! -Matt Nope -- it was a genuine virus copy, self-replicating through the list. Stupid Outlook executes everything .vbs even if the attachment has application/octet-stream content-type. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Thu, 6 Apr 2000, Nikolai Saoukh wrote: koi8-r, one of the oldest cyrillic charsets, primarily designed to keep "intuitive" mapping to ASCII, to remain usable after passing through characters-mangling old software and to be readable on 7-bit dumb terminals -- and the last mentioned property is still saving a lot of trouble for Russians that use mail-to-pager systems. History is more complex than some people think. Wrong, you are comparing apples and oranges again -- cyrillic (8859-5) encoding with russian (koi8-r) one. Never say never -- if you do not know about 8859-5 usage is does not mean "not used by everyone". I am absolutely certain that my knowledge of the cyrillic encodings usage and history that I have got in fourteen years of dealing with them is complete. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Thu, 6 Apr 2000, Anatoly Vorobey wrote: Can you guess, which one of of multiple cyrillic charsets never was actually used in Russia? ISO 8859-5. It's actually being used quite often now by users of MS Outlook 2000 (those of them not sophisticated enough to select their own outgoing encoding). Unless Microsoft turned around its encodings policy one more time last year, Outlook by default uses Windows CP-1251 for cyrillic. And which is still the standard in Russian-language newsgroups, for russian Unix users and most of Russian-language web pages? Cyrillic!=Russian. The same applies to the use of encodings for Ukrainian language except that koi8-u (that us a superset of koi8-r) is used instead. Other languages either aren't used widely enough to provide any statistics (such as Belorussian), or use one of existing charsets other than iso8859-5. koi8-r, one of the oldest cyrillic charsets, primarily designed to keep This is untrue. cp1251 is used in almost all Russian web pages, and koi8-r is the minority (for no good reason, of course, primarily because too many people never learned to set the right charset in the outgoing HTTP headers). While the number of russian pages in CP-1251 is increasing, I probably look at the "wrong" web sites because absolute majority of what I have seen either uses koi8-r, or offers multiple encodings, including koi8-r and CP-1251 but never iso 8859-5. "intuitive" mapping to ASCII, to remain usable after passing through characters-mangling old software and to be readable on 7-bit dumb terminals -- and the last mentioned property is still saving a lot of trouble for Russians that use mail-to-pager systems. History is more complex than some people think. And with all its attractive properties, it's still missing the letter "yat'" that I need. It's there in Unicode, of course (and in 8859-5). With multiple-charsets support it's still can be available, however this is not the point. The reality is that this letter is completely excluded from any real-life use for more than 70 years. That is, everything published in modern Russian, even if it is a re-published work that originally used pre-reform Russian language, is printed in post-reform version of the language, works of Pushkin and Tolstoy included. The only cases where "yat'" is used are ones where exact reproduction of works in documents is necessary, and generally are treated by Russians as texts in languages that is not recognized as Russian anymore (as well as even earlier version of Russian that had significantly different alphabet and can't be read by modern Russians without archaic-language training). In other words, you are talking about completely different language. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Fri, 7 Apr 2000, Kazutaka YOKOTA wrote: Multilingual text processing in the userland is a completely different issue which, I think, should be discussed separately. I agree with this completely. The question is, where? -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, G. Adam Stanislav wrote: On Tue, Apr 04, 2000 at 07:19:06PM -0700, Alex Belits wrote: It is. However if you look at the current efforts of its "adoption", it is not used as one. It's touted as the solution to all language-related problems, as a replacement of language/charset labeling infrastructure and as the necessary prerequisite for any multilingual text processing. Abusus non tollit usum! Besides, you were criticizing the Unicode Consortium for this. The Consortium is certainly not representing Unicode as anything but a character map. Actually I criticize IETF, W3C, software companies and "internationalization" standards that they produce. Unicode consortium has its own share of troublemaking and arrogance, however replacement of languages support with Unicode adoption became the IETF policy on "internationalization". Alex, frankly, we are moving in circles here. Let's drop this thread. Huh? -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, Taavi Talvik wrote: the _replacement_ for languages/charsets handling infrastructure -- "we know all the characters, so we can write all the words, right?". Multilingual tools market and small? Get real - just China and India together are 2 billion possible users. They don't use "true multilingual" software -- they have their own charsets and encodings, and are quite content with them, not having to care about others' charsets. Contrary to popular belief, Chinese and Japanese are not waiting for benevolent American programmers to provide them with "multilingual" software -- they just use local charsets in existing one, sometimes having to modify it (in rather ad-hoc manner) to support multibyte where necessary. It can be called shortsightedness or isolationism, but this is how things are -- market for true multilingual software is in its infancy. Poorly designed solutions for multilingual documents handling are considered to be acceptable because people who are "targeted" by them neither use them nor really care about multilingual documents, and people who actually use those things have very limited applications. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, Anatoly Vorobey wrote: that the way that TeX handles such a text is even more inconvenient, however even now it's most likely that TeX would be used for this kind of typesetting. But we're *not* talking about typesetting -- rather about multilingual text handling. TeX, indeed, does typesetting and thus solves the wrong problem. It solves exactly the same problem -- displaying information. Unicode does NOTHING to support any other functionality that is required for true multilingual text processing. You can't even do a hyphenation of unicode text -- you will have to guess, which language rules should apply. In "real life" someone who needs to handle text with Russian and French in it -- type it, send it, read it, study it, etc. -- not *typeset* it -- won't use TeX for it, but will rather walk over to the Windows machine and fire up Word. This is the solution that's used in "real life" right now This only happens because those people use Word, and Word happens to use Unicode. Well, Word uses a lot of things that I consider to be stupid and poorly designed -- its popularity is based definitely not on technical merit. -- and incidentally, one of the reasons it's become so annoyingly common to email Word files as some kind of universal text standard. Word is not a standard, it's a format forced on a lot of people by some pretty shady practice of certain company that in few recent days was mentioned often enough to make it pointless to be described again. I don't like this, but currently the Unix world doesn't have a good alternative to offer. UTF-8 changes that, and I think that's a wonderful thing. UTF-8 provides a way to display a lot of characters -- that's all. And this is nowhere close to being enough -- if we want to be superior to pretty-pictures-oriented Windows software, we need to provide advantages over it, not absorb its weaknesses. We need to provide multilingual functionality, not just multilingual display -- if that will be done, half-assed languages support in Windows/Word will look like a sad joke. It's fine for you to talk about what would happen if MINE were to evolve into a general-purpose text-marking standard powerful enough to handle a Czech word inside a French sentence, but that didn't happen, which means that neither you nor anyone else took it there. Frankly, I don't think MIME would have been up for the task anyway, but that's a moot point because it just didn't happen. What do you mean, "didn't happen"? Who is here writing software but we ourselves? I am trying to explain why the development in that area should be done despite stupid decisions made by IETF precisely because I expect it to be done as the result -- by myself or by others. I will be happy to start this work, however without others' input I am afraid that it will become yet another thing based on idiosyncrasy rather than on good design ideas -- sad example of Java makes me feel rather uneasy about starting a thing that no one seems to understand or care about. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, Jason wrote: i18n needs such as non-English users? Linguists don't see Unicode as being sufficient, What do you mean by "Linguists don't see Unicode as being sufficient"? Where I work, we have a gaggle of linguists and are currenly posting our software to UNICODE (UCS-2 encoded). Actually, of all people, the "linguists" seems to like it the most (besides some wanting UCS-4). Lack of extensibility and variants. Don't they just love the great extensibility means aka non-standardized and non-standardizable "private use area" that defeats the whole idea of having a standard charset? -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On 5 Apr 2000, Christian Weisgerber wrote: the most inclusive one in existence. It is. However if you look at the current efforts of its "adoption", it is not used as one. It's touted as the solution to all language-related problems, as a replacement of language/charset labeling infrastructure Who says so? Certainly not the Unicode enthusiasts I have met. You are arguing against a strawman. I would be happy if it was a nonexistent point of view, however it happens to be exactly what I hear from people who are trying to "standardize on UTF-8" FTP, HTML, NNTP and even DNS. Their arguments? "who needs any other charsets or languages? just force everyone to replace them with UTF-8, put UTF-8 handling into all software and all languages-related problems will be solved". One of shining examples of this is someone Martin Duerst, however he is not alone there. [skipped] A claim that would be obviously absurd. However, I do consider Unicode a sensible part of any new implementation. ISO 2022 (and what other dinosaurs that may be lurking in murky shadows) is a legacy solution that should die off. iso 2022 is a dinosaur -- it's inflexible. However labeling of charsets and languages in general is definitely necessary for any decent languages-handling functionality. Even if the charset is Unicode, languages still have to be labeled somewhere to make any use of the text in processing, and if labeling is unavoidable, multiple-charsets model is in no way inferior to Unicode, plus it allows easy addition of charsets and variants of them without Unicode consortium approval as long as something handles the charset and language names. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, G. Adam Stanislav wrote: On Wed, Apr 05, 2000 at 03:51:29PM -0700, Alex Belits wrote: I think, I have heard statements like this way too much in my life -- "Communism is the bright future of the humankind -- this goal hasn't been achieved yet, but Communist Party is..." Sorry, but I see too many similarities. Give me a break! I grew up in a Communist country. A remark like that is a slap in my face. Especially from someone who, obviously, has personally experienced Communism. I could see a Montana Freeman making a comparison like that, but not a Russian emigré. I refer only to my idea of the possible validity of the statement, I have no intention to actually compare Unicode Consortium and Communist Party. To compare Unicode to the suffering imparted by the Communists on almost two thirds of the world is ridiculous in the least, and outright offensive. This is not a place to discuss my feelings toward political doctrines, however I don't see why hatred toward communists is supposed to be somehow "sacred". I always considered that people have unlienable right to poke fun at all kinds of troubles that they faced, and I think that with 23 years spent in Russia I qualify for that pretty well. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, G. Adam Stanislav wrote: Lack of extensibility and variants. Don't they just love the great extensibility means aka non-standardized and non-standardizable "private use area" that defeats the whole idea of having a standard charset? Absurd! The private use area is for application specific usage. Suppose you want to design a database of cleaning supplies. You create a font for the use with your application, which will draw soap, mop, towel, and things like that. These are not in Unicode, and your odds of convincing the Consortium to include them are slim. So, your application will assign points within the private use are to soap, mop, towel, etc. This is what it was intended for, however this is not how it is used. I understand why Unicode Consortium is unlikely to include Klingon alphabet into "blessed" by them charset, however the use of private area for Klingon is hardly application-specific. When instead of fictional (even though relatively well-known) charset the question is about the representation of "obscure" or even hypothetic details of some real-world charset, things become much more hairy. Labeling of charsets and languages in multiple-charsets environment (even if in the case of Klingon the "charset" is Unicode with something added in the private area) can eliminate ambigiuty without involving ISO, Unicode consortium, etc. and without destabilizing "standards" by constant changes. You are fighting wind mills, my friend. [ witty comment about Klingons and windmills is left as an exercise to the reader ;-) ] -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Thu, 6 Apr 2000, Patryk Zadarnowski wrote: without destabilizing "standards" by constant changes. Can it? People have been begging ISO to standarise 8 bit charsets for ages. If you tried to exchange information in polish in the pre-8859 days, you'd know why (about five radically different charsets in common use) Besides, if the alphabet for information interchange doesn't deserve standarising, I don't know what does. Can you guess, which one of of multiple cyrillic charsets never was actually used in Russia? ISO 8859-5. And which is still the standard in Russian-language newsgroups, for russian Unix users and most of Russian-language web pages? koi8-r, one of the oldest cyrillic charsets, primarily designed to keep "intuitive" mapping to ASCII, to remain usable after passing through characters-mangling old software and to be readable on 7-bit dumb terminals -- and the last mentioned property is still saving a lot of trouble for Russians that use mail-to-pager systems. History is more complex than some people think. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, G. Adam Stanislav wrote: At 20:59 03-04-2000 -0700, Alex Belits wrote: I feel perfectly fine with "multilingual" documents that contain English and Russian text without Unicode. Those are bilingual, not multilingual. I once had to create a document in English, Slovak, and Sanskrit (using Devanagari alphabet). There is only one standard that makes it possible: Unicode. Too bad UTF-8 did not exist at the time, and I had to use graphics. There is another format that does the same thing better -- MIME multipart documents. Too bad, the development in that direction stopped after certain stupid decision made by some people in IETF. Everyone who wants to follow a single international standard as opposed to a slew of mutually exclusive local standards. Anyone who thinks globally. "Globally" in this case means following self-proclaimed unificators from Unicode Consortium. I don't know what you mean by "unificators." Why self proclaimed? Those were people with a need for which they found a solution. With a need to find a cause to break backward compatiobility with everything and sell more software -- just like ITU. I agree that Unicode created a good list of glyphs, and it can be useful for fonts and conversion tables, but it's completely inappropriate as the base of format used in real-life applications for storage and communications. Unicode Consortium has no power to force Unicode on anyone. It just happens that it was widely accepted. So far only by one company actually "accepted" it -- Microsoft. Everyone else (except Java/Sun) just happened to be depended on them. Java and Plan9 are special cases because both are essentially endless storages of ivory-tower design idiosyncrasy and arbitrary decisions made by handful of people. You're free to create your own system, or ignore it all together. But just because you see no need for Unicode does not mean you should be upset when people are willing to work on Unicode support in FreeBSD. I have just asked, who will benefit from it. No one answered "I will" -- everyone who makes Unicode support believes that it will benefit someone else. Anyone who has anything to do with the Internet must deal with UTF-8: "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text." RFC 2277 This is not approved by ANYONE but a bunch of "unificators". It never was widely discussed, and affected people never had a chance to give any input. This is the same kind of "standard documents" that ITU issues by dozens. Affected in what way? Many ways of encoding Unicode were proposed, developed, and used. Most of them are history by now. UTF-8 is the best way to encode Unicode to this day. Don't like it? Design a better one. I am not talking about Unicode representations and encodings but about Unicode itself. I agree that UTF-8 is the only way to marry Unicode with text and Unix, however I don't see much point in doing that. -- I am Russian. So? So I don't want UTF-8 to be forced on me. Who's forcing it on you? IETF. All recent RFCs are littered with referenced to UTF-8 in all places where reasonable standards would have "8-bit clean" with no explicit low-level semantics attached. Charset definitions in MIME headers exist for a reason. If we want to make something usable we can create a format that can encapsulate existing charsets instead of banning them altogether and replacing with "unified" stuff where cut(1) and dd(1) can produce the output that will be declared "illegal" to be processed as text because it can not be a valid UTF-8 sequence. You are worried about nothing. No one in this discussion has said anything about making anything but Unicode and UTF-8 "illegal." Supporting Unicode does not mean stopping support for everything else. I have spent enough time with "unicoders" to become convinced that the depth of changes they demand in protocols and libraries is enough to make it a game of "everything or nothing" -- partial implementations become unsafe because the design of libraries and prococols hinges on the idea that only one charset/encoding may exist, so no ways to provide charset and encoding are left. One of the most basic strengths of Unix is the ease with which text can be manipulated, and how "non-text" data can be processed using the same tools without any complex "this is text and this is not" application-specific procedures. Nothing complex about it. UTF-8 uses a very simple algorithm which makes it very simple to distinguish text from non-text. This is the problem. There is no "tex
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, G. Adam Stanislav wrote: At 22:51 03-04-2000 -0700, Alex Belits wrote: I agree that Unicode created a good list of glyphs, and it can be useful for fonts and conversion tables, but it's completely inappropriate as the base of format used in real-life applications for storage and communications. Oh, I think it's great for communications. I design web sites. It is good to have a single character representation supported by Internet standards. Saves a lot of work. Before UTF-8 became widely accepted, a typical Slovak web page started by a menu of choices of which encoding your browser supported. You had to have 3 - 4 versions of each page. A major pain! Now you only need one. This is a problem, however Unicode is not the only solution -- actually it's the worst of all solutions -- it solves simple problem only to create a lot of complex ones. Or even when designing English pages in a typographically correct way (opening and closing quotes, and things like that), it was a pain before UTF-8 because while ISO-8859-1 is the assumed default, Microsoft, in its infinite wisdom created a slight modification of ISO-8859-1 which they called ANSI, and which the uninitiated commonly believed to be the same as ISO-8859-1. As a result, there are a myriad of web pages out there that use the Microsoft encoding, and there are those that use true ISO-8859-1. So many browsers assume that you are using the MS "standard." It's a real mess. Misrepresentation of one popular encoding in software of one company doesn't mean that it should be replaced with another, much more complex one, by everyone else. So, in all my recent pages I use UTF-8, and the problem is solved. Unicode Consortium has no power to force Unicode on anyone. It just happens that it was widely accepted. So far only by one company actually "accepted" it -- Microsoft. Everyone else (except Java/Sun) just happened to be depended on them. Java and Plan9 are special cases because both are essentially endless storages of ivory-tower design idiosyncrasy and arbitrary decisions made by handful of people. I was not talking about companies. I was talking about people with genuine i18n needs. People with genuine i18n needs such as linguists or people with genuine i18n needs such as non-English users? Linguists don't see Unicode as being sufficient, and everyone else uses local encodings/charsets. I agree that local encodings are very limiting in the form they exist now, however they, not Unicode, are standards used in real life. If some encapsulation format (not as limited as iso 2022 and not as restrictive as MIME multipart) will be created to support multiple charsets/encodings/languages in one document in labeled chunks, the same problem would be solved with minimal changes in existing software and minimal document conversion efforts. This solution will be far superior to Unicode, and even for "web" use it can be made compatible with charsets support in existing browsers. [skipped without much of disagreement] Again, it's not about "adoption" of Unicode, it's about supporting Unicode for those who need it. Going Unicode-only would not be wise, but I don't see anyone here suggesting that. After looking at what happened to IETF documents, XML and perl I can only come to conclusion that Unicode, once included in some system that didn't have multiple-charset document support infrastructure before that, starts requiring more and more sacrifices to be supported decently until the support of other encodings becomes impossible or significantly more difficult than support of Unicode. I am not against the support of any charset, encoding or language used in the real world, Unicode included. However after seeing how Unicode "support" efforts quickly turn into "adoption" all across the libraries/protocols/applications layers, I believe that only if some decent charset/encoding/language labeling infrastructure will be developed, it will be possible to contain charsets and prevent their "leaking" to application level. Leaking of ASCII (infamous 7-bit restriction that was present for no understandable reason in a lot of protocols and utilities) was a painful enough experience already, and it looks like it's fixed in most of stuff by now. Leaking of local charsets (especially iso 8859-1 and its modifications) was bad, however it was mostly prevented by locale support (even though it is clumsy and unusable in multilingual documents). Leaking of Unicode and UTF-8 can start something even worse because it's already evident that many applications written to support UTF-8 character format, have the hardcoded assumption of this format in their i/o and parsing routines that otherwise are supposed to be either charset-blind, or use external, charset-dependent routines to determine characters boundaries. I don't want to be misu
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, Garance A Drosihn wrote: I don't understand what possible benefit there is in having *NO* options to deal with all the language-characters in the world. Even if unicode isn't perfect, it is a damn sight better than nothing. The existing "market" of multilingual application is so small, and it's based on so simplistic requirements (to be able to display and print characters, and make multilingual "web pages"), that even solution so much flawed as standardization on Unicode can survive. Unicode is positioned as the _replacement_ for languages/charsets handling infrastructure -- "we know all the characters, so we can write all the words, right?". As demands for sopisticated processing of multilingual texts will increase, "Unicode-only" systems will demonstrate their ridiculous limits and ambiguity, however if no multiple-charset/multiple-language infrastructure in libraries, formats, protocols, text and document editors and interpreter-based programming languages will be in place, there will be no way to improve the situation. This is why I think that the design of the language support infrastructure is an extremely important taks, and if it will succeed, efficient, modularized support of charsets/encodings, including Unicode, can be implemented painlessly. If some specific change for unicode does break things, then I can see arguing that change. I can't fathom why anyone would argue against unicode support per se. I am not against the support for Unicode. I just never have seen an attempt of providing usable Unicode support that didn't leave scorched earth to any other possible attempt of supporting multilingual environment or even single-charset environment other than iso8859-1 or Unicode. I think that instead of blind following the ideas of "one charset" we need to design something that can painlessly accept various charsets in the same document/stream/etc (just like MIME does in its own clumsy way). If Unicode support will be implemented on top of it, I will be the last person to criticize it. -- Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, Alex Belits wrote: You mean, MIME multipart documents are better than Unicode if I, for instance, want to handle Tolstoy's "War and Peace" with French quotes in the middle of Russian sentences? I don't think so. This is what multipart format exists for -- to combine documents or sections in the document with possibly different metadata in the headers. The idea of "mail attachment" appeared later. I have to add that I agree that the way, MIME multipart is handled is primitive and inconvenient for such applications, however this is not the result of any flaw in its design, only of the lack of progress after "everything should adopt Unicode" doctrine was declared. One may argue that the way that TeX handles such a text is even more inconvenient, however even now it's most likely that TeX would be used for this kind of typesetting. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Tue, 4 Apr 2000, G. Adam Stanislav wrote: On Tue, Apr 04, 2000 at 05:05:05PM -0700, Alex Belits wrote: The existing "market" of multilingual application is so small, and it's based on so simplistic requirements (to be able to display and print characters, and make multilingual "web pages"), that even solution so much flawed as standardization on Unicode can survive. Unicode is positioned as the _replacement_ for languages/charsets handling infrastructure -- "we know all the characters, so we can write all the words, right?". Not so. Unicode is a character map. One of many. It just happens to be the most inclusive one in existence. It is. However if you look at the current efforts of its "adoption", it is not used as one. It's touted as the solution to all language-related problems, as a replacement of language/charset labeling infrastructure and as the necessary prerequisite for any multilingual text processing. [skipped] It does not, for example, provide sorting order. It cannot. Unicode is not about linguistics, it is about mapping characters regardless of their use in specific languages. And different languages sort characters differently. For example, in Slovak, "ch" is considered a character which belongs after the "h". In other languages it is sorted differently. And in most languages, it is just two unrelated characters. This is the kind of work that currently nonexistent language support infrastructure should do -- when some language is encountered in "multilingual" document/protocol/... its name can be used to load the procedures (in this case sorting but it may be hyphenation, phonetic match, etc.) for that particular language, and if no matched language is known or supported, data should be just left alone. The same infrastructure can be designed to support charsets and encodings, doing conversion between them (and unicode) only where possible and necessary, and providing the text in either "original" or "preferred", "supported", etc. encoding for the language for the particular operation that should be performed on the text. If such thing will be implemented, all existing charset-specific routines that now exist in various places, can be reused, and compatibility with existing software can be achieved without any significant pain. Unicode is not simplistic. It does what its stated goal is, and it does it well. How we use it, is up to us. Cheers, Adam P.S. Hmmm... Interesting. I noticed my random quote contains a C-caron. I wonder how it is going to be handled. :) It was handled pretty well for such a primitive system as pine in xterm. Since your charset was iso 8859-2, it was marked as such in Content-Type header of the message. pine given me a warning: ---8--- [ The following text is in the "iso-8859-2" character set. ] [ Your display is set for the "koi8-r" character set. ] [ Some characters may be displayed incorrectly. ] ---8--- and displayed the text. xterm used the default font that happened to be in koi8-r charset, displaying C-caron as cyrillic ha. I have read the warning, manually switched xterm to a font in iso 8859-2 charset, and text was displayed correctly. If I used a gui-based MUA such as Netscape (what I didn't because Netscape Messenger sucks for reasons that have nothing to do with its charsets support), it would just display the message in the charset defined in the header. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 20 Mar 2000, MikeM wrote: Has anyone thought of Unicode support on FreeBSD? Really the question is much more basic -- who benefits from having Unicode (or Unicode in the form of UTF-8) support. It isn't me for sure -- I am Russian. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Mon, 3 Apr 2000, G. Adam Stanislav wrote: Really the question is much more basic -- who benefits from having Unicode (or Unicode in the form of UTF-8) support. It isn't me for sure Everyone who works with multilingual documents. I feel perfectly fine with "multilingual" documents that contain English and Russian text without Unicode. Everyone who wants to follow a single international standard as opposed to a slew of mutually exclusive local standards. Anyone who thinks globally. "Globally" in this case means following self-proclaimed unificators from Unicode Consortium. Anyone who has anything to do with the Internet must deal with UTF-8: "Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text." RFC 2277 This is not approved by ANYONE but a bunch of "unificators". It never was widely discussed, and affected people never had a chance to give any input. This is the same kind of "standard documents" that ITU issues by dozens. -- I am Russian. So? So I don't want UTF-8 to be forced on me. Charset definitions in MIME headers exist for a reason. If we want to make something usable we can create a format that can encapsulate existing charsets instead of banning them altogether and replacing with "unified" stuff where cut(1) and dd(1) can produce the output that will be declared "illegal" to be processed as text because it can not be a valid UTF-8 sequence. One of the most basic strengths of Unix is the ease with which text can be manipulated, and how "non-text" data can be processed using the same tools without any complex "this is text and this is not" application-specific procedures. UTF-8 turns "text" into something that gives us a dilemma -- to redesign everything to treat "text" as the stream of UTF-8 encoded Unicode (and make it impossible to combine text and "non-text" without a lot of pain), or to leave tools as they are and deal with "invalid" output from perfectly valid operations. In Windows/Office/... that lives and feeds on complex and unparceable formats this problem couldn't appear or even thought of -- "text" doesn't exist as text at all, and the less stuff will look as something that can be usable outside of strict "object" environment, the better (they now don't even encode it in UTF-8, and use bare 16-bit Unicode). In Unixlike system it's a violation of some very basic rules. -- Alex P.S. I expect that Martin Duerst, the source of 80% of Unicode propaganda on the software-oriented mailing lists will appear within 72 hours here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthread blocking I/O
On Mon, 6 Mar 2000, James FitzGibbon wrote: Some comments? Isn't so? In my experience, threads are the perfect way to speed up an I/O bound application. While one thread is blocked in iowait, others can be performing operations that do not contend for the same resource (calculation, I/O on some other resource like a socket, etc.) Processes can do it better, and if i/o can be nonblocking, plain poll()/select() loop can do even better (pathological cases of Java and applications ported from Windows being the exception). This is of course implementation dependant; if you are using a user-land thread package like MIT pthreads, the kernel sees the entire process as one schedulable entity, so if one thread blocks on IO, all threads block. Not really. What looks like blocking i/o for you can be nonblocking for kernel if your threads support library translates it. If you are using a kernel-thread or hybrid implementation, the system scheduler allows the other threads to run as described above. FreeBSD's threading implementation in libc_r is (AFAIK) a hybrid model, and from personal experience I have found threaded applications under FreeBSD to be much easier to code for performance than their single-threaded counterparts. My experience is the opposite -- if data structures are complex enough to become a pain in the ass to lock, processes allow more simple design than threads, and nonblocking i/o usually limits complex code to some small piece of program that can be written/optimized/debugged once, then left alone. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netscape Bus Error
On Tue, 28 Sep 1999, Darren R. Davis wrote: I believe that a Bus Error is specifically referencing miss aligned data vs segmentation violation (SIGSEGV) which is accessing data that is either free'd or not yours, etc. I always thought it strange on an Intel processor, since this was more a 68K/RISC thing. The only penalty on Intel was taking many more cycles to complete. Of course I haven't looked that deeply at what the code handling for the bus error signal really detects. But, never the less, it is still a Netscape bug. It's SIGSEGV in disguise -- netscape intercepts it and generates SIGBUS: ---8--- abelits@es1840$ netscape [1] 67114 abelits@es1840$ kill -SEGV 67114 abelits@es1840$ [1]+ Bus error netscape abelits@es1840$ ---8--- -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hardware
On Fri, 9 Jul 1999, Axis wrote:
I have been using *BSD* for around 3 years now. My problem is thatI have
always used the console for system administration duties. I really want to
put a kick *** system together to run X with all of the luxuries.
I have noticed there is not that much support for sound cards andvideo
display adapters.
Given your experience, Could you please inform me of which sound card and
video display adapter works best with FreeBSD.
This became more complex recently when a lot of new stuff appeared in
XFree86, but without that much of kicking ***es, Matrox Millennium G200
AGP and SB AWE64 ("Gold" or "Value") is a cheap and decently supported
combination.
3D features of G200 are currently unsupported, but 1. you probably don't
need them anyway, 2. it's expected that this will be one of the first
3D-accelerated cards, natively supported with GLX in XFree86.
FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity;
They are all better than LINUX or (Like Its Not UNIX). :)
[flame skipped].
--
Alex
--
Excellent.. now give users the option to cut your hair you hippie!
-- Anonymous Coward
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: hardware
On Fri, 9 Jul 1999, Axis wrote: I have been using *BSD* for around 3 years now. My problem is thatI have always used the console for system administration duties. I really want to put a kick *** system together to run X with all of the luxuries. I have noticed there is not that much support for sound cards andvideo display adapters. Given your experience, Could you please inform me of which sound card and video display adapter works best with FreeBSD. This became more complex recently when a lot of new stuff appeared in XFree86, but without that much of kicking ***es, Matrox Millennium G200 AGP and SB AWE64 (Gold or Value) is a cheap and decently supported combination. 3D features of G200 are currently unsupported, but 1. you probably don't need them anyway, 2. it's expected that this will be one of the first 3D-accelerated cards, natively supported with GLX in XFree86. FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity; They are all better than LINUX or (Like Its Not UNIX). :) [flame skipped]. -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: USENIX scribe bit
On Thu, 27 May 1999, Doug White wrote: If anyone had a DV (FireWire) camera they could make available, I could ship my mac G3/350 down and edit the data it into video clips, then serve it with QuickTime Streaming. Put together a decent webpage for it all ... burn it to CD... whee ... :) Won't it be umm... ironic considering that new Quicktime doesn't and won't work on anything that even remotely resembles Unix? -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
