There's some hardware out there that does that, look for hardware you can use with Asterisk (I remember thinking of setting up a PBX, it was a bit pricey but I don't remember details). It is a bit pricey indeed.:) That's very much the reason why I started building my own instead. Plus, I wanted to be able to use it on its own, not just with Asterisk.
Also, if you've got a soldering iron or a crimper you could just create a RJ45-to-mic-plug adapter, not sure if that would work though. It would work with a few support components if I only wanted to listen to a phone call. If I wanted a two-way interface, I'd be able to do that as such with the two-to-four-wire adapter I mentioned in my original post (GGGP), but that would exclude support for such things as hook control and ring detection. And if I am to integrate that as well, connecting it to an AVR microcontroller and create a USB interface is the least problem anyway.
In all honesty, what does one do with Visio? I've been wondering for the longest time. I have really only seen Visio on a superficial level, but it didn't seem to be more than a somewhat fancy drawing program with a library of symbols, which made it seem quite a bit like Dia to me (except the library was larger).
While it is obvious that Google Spreadsheet has it wrong, it does seem to me as if that Octave function of yours gives the wrong answer as well (however, I couldn't even find the nchoosek function in my Octave installation).
However, that Octave gets such a thing wrong is hardly surprising. Octave's strength never was to do arithmetics with large integers. In fact, AFAIK Octave never uses integers at all; I'm pretty sure it always uses floating point numbers, so when doing calculations on such large numbers (55! / (27! * (55 - 27)!)), it is hardly surprising that it truncates the numbers somewhere along the line.
When I calculate the same binomial in Emacs Cals, I get 3824345300380220, which is extremely close to Google Spreadsheet's answer. I cannot really imagine how they manage to add that extra 0.5, though.
sed 's/readSlashDot\(\)/meetWomen\(\)/g' braindump.txt Oh please! Everyone knows that sed uses old-style regexes, where `\(' and `\)' are subpattern delimiters, not literal parentheses. Furthermore, you'd never need to escape parentheses in the replacement part of the command (unless, of course, you use parentheses as command part delimiters).
I can't really tell whether you're joking, but in the likely case that you are, I'm quite serious about the idea. It would just be a simple telephone line to USB interface, implementing the standard USB sound card protocol (with some extensions for "hook" control), hence becoming a simple and cheap way to implement a VoIP to PSTN bridge. I'm quite excited about the possibility to either be able to do normal PSTN phone calls with a bluetooth headset, or be able to answer my phone at home when I'm actually not at home, using my laptop.
The reason I used the formulation "modem with the modem part" is just because that's one of the comments I got on the project in real life.:)
Where multiple jacks are connected to the same wire run, the red is connected to the red, black to black, etc. There's no crossover between the two pairs. I see. I guess the daisy-chaining part is just a Swedish invention, then. I knew that other countries use two-wire circuits for terminal equipment as well, since I've been able to take telephone equipment from other countries and have it work over here, but it was just my assumption that they used daisy-chaining as well (since they didn't break the line). For reference, the kind of plug used is described on Wikipedia.
Maybe I'm somehow misinterpreting you, but you speak as though two-wire circuits were a thing of the past, which is about as far from reality as one could get. Virtually every subscriber connection in the any part of the world that I've checked is a two-wire circuit, and that includes at least Sweden and the US. In case anyone is wondering, the reason there are four wires in every wall socket is because the telephones are daisy-chained together -- two of the wires just continue to the next wall socket (I wouldn't bet about the daisy-chaining being true in the entire world, though -- they could be connected in parallel as well). One single telephone only uses two wires when you use it to talk.
Just for reference, the reason it was designed that way is because in the beginning of telecommunication, the exchange station would just feed 48 V into a line on which the microphones and speakers of both participating telephones were simply connected in series. It's obviously an extremely simple design; befitting the era, I guess. I don't know how it is done these days, but in the days of old, capacitors and resistors weren't used to cancel out feedback, but rather a very special transformer circuit called a duplex coil. Nowadays, it seems to be hard even to find information on how it was constructed.
You might wonder why I know these things; it is simply because I've been trying to design a "telephone soundcard" (like a modem, but without the modulation/demodulation part). It turns out that it is rather easy to construct a converter from a two-wire circuit to a four-wire circuit using two opamps and five resistors. Of course, that won't make the line unloaded.
The photographer takes a picture, posts it on Flickr with a license that allows for commercial use. Once someone uses it commercially he/she sues the commercial user and the author of the license?
Maybe there should be a "3) Profit" in there as well?
That was my first thought as well; I thought they had to be retarded. But then, I did something quite unusual -- I RTFA:d. Here's a quote:
In the ad, Virgin Mobile printed one of its campaign slogans, "Dump your pen friend," over Alison's picture.
The ad also says "Free text virgin to virgin" at the bottom.
That makes it quite a lot different, in my mind. It's one thing to put a vacation photo or similar up on the Internet under a CC license as to allow people to use it as such: as a vacation photo. It's another thing to take that picture and superimpose some message that you may not at all stand for.
I would imagine that if I took a picture of myself in front of my computers and put it under a CC license, and Microsoft then used it in one of their advertising campaigns superimposed with the slogan "Get the Facts" or something like that, then I'd be pretty pissed too.
I do recall someone telling me that no CPU would ever run at more than 2GHz, as it would then start emitting microwave radiation... Thinking of it, it would make sense. Really, how comes they don't? Are they just sufficiently shielded?
Yeah, but it doesn't mention if it will be forward compatible, so that you can plug 3.0 devices into a 2.0 port, as you can with 2.0 devices and 1.0/1.1 ports.
Furthermore, I just can't help thinking it seems kind of stupid with optical links if they want it to truly take the standard over from USB 2.0. I would think it much harder to produce cheap devices that need to include optical transceivers. One of the great advantages of USB in my mind was always that it's very easy to design "client" devices -- you just hook it into your microcontroller and add a couple of capacitors and resistors. But I don't know, maybe they plan to build the optical transceivers directly into the connector, so that the device designer won't even have to think about it.
Another problem seems to be the connection between the HCI and the actual host interconnect. 4.8 Gbps would require at least two PCIe lanes. I doubt many people will want to waste a 16x PCIe port on their motherboards to connect a USB HCI card, and all too few motherboards seem to come with 4-lane connectors. Sure, that won't be a problem once motherboards start integrated USB 3.0 HCIs, but what about until then?
Yeah, they do, but only on your own side. Commonly, the other side's client will still transcribe your smilies to something much more sinister on their side. It could be argued that that is mostly the problem of the person on the other side, but that isn't entirely true; I often find that the stock smilies used by many IM clients look like something that far from always actually conveys the mood you're trying to set with a certain smiley. But, I digress.
It may not be the answer you'd like, but I'd say that if such an MP3 player does indeed exist, it would probably more or less have to be some kind of PC anyway (otherwise, there'd be no point in even making a "large" one, if one could suffice with a portable MP3 player constantly hooked up to the power jack). So if you're going to get one anyway, why not just resign yourself and use a retired PC? It's not as if it would be more expensive than buying any sort of dedicated, AC-hooked MP3 player anyway.
When I saw the headling "Inside the Third Gen iPod Nano", I was expecting some serious hard{core,ware} porn. Boy, was I disappointed! For any others looking for the true meaning behind the headline, let me refer you to a google result.
Speaking of which -- on those pictures, I see no Samsung CPU as the summary stated. The only major Samsung chip I can see is the flash chip.
Here is Linux's NFS v4 architecture. Other implementation's use kerberos too. Kerberos is one of the major improvements to NFS v4. In all honesty, though, Kerberos isn't precisely new to NFSv4, it's just that support for it has been mandated by NFSv4. Kerberos authentication is supported at the RPC layer, which is the same regardless if being used for NFSv4, v3, v2 or even portmapper, NIS or SGI FAM, if you will. AFAIK, Linux's NFSv2/3 implementation supports Kerberos authentication as well, ever since the support was added to support NFSv4. I shan't bet on it, but I think Solaris has supported Kerberos authentication for earlier NFS protocols for quite a while.
The actual improvements in NFSv4 include such things as compound calls (which is, on a completely unrelated note, also a new feature in Microsoft's SMB 2.0) which, at least supposedly, improves performance due to network latency. It also included symbolic UID/GID mapping (rather than working with numerical IDs). It also works better through firewalls by using a single TCP connection for everything (although personally, I think the firewall problem should be fixed instead...). While there exists an extension for POSIX APIs for NFSv3, NFSv4 has ACL support on its own, and I think it supports XATTRs as well (though the Linux implementation doesn't yet).
I'm pretty sure it includes other improvements as well, but I cannot remember any others right now. For me, the most important feature of the new protocol as such was the symbolic ID mapping, since it means that I can access my NFS home directories on my laptop without also having to use NIS and other things that wouldn't work when I take the laptop out from my home network.
From what I've been able to tell from the discussions on the IETF's IPv6 mailing list, it probably won't just be corporate networks going with DHCPv6. The greatest problem with IPv6 autoconfiguration (probably since its inception) is the fact that while you get a network address, you don't get any information about available DNS servers, which no modern IP node can do without in reality.
There have been a number of suggestions to solve it that problem, of course, ranging from adding an extra field for DNS servers in the autoconfig ICMP messages to using well-known unicast addresses for the closest recursive DNS server to using a dedicated protocol just to discover DNS servers. The first and last of those have (rightfully, IMNSHO) been shot down because then one might "just as well" use DHCP, which exists and has a solution ready for the issue at hand. I cannot remember why the unicast suggestions have been rejected, though, and it has been disturbing me, because I think it is the best solution. I really just cannot see the drawbacks to it. I guess there might have been some talk about lack of security in that model, but that's a problem with DNS in general, though. That's why DNSSEC was invented.
Last I looked, the consensus seems to be to use autoconfig for address generation, and then request network information (such as DNS servers) from a link-local DHCPv6 server. When everything comes around, I think that's a rather good solution. Clients can still get whatever non-occupied address they want (which means the privacy extensions will also continue to work), and still get the information they find relevant, and a DHCPv6 server should be easy to implement on a network of any scale.
What good is it they fined them nearly a billion. Will this help us somehow. (To begin with, let me tell you about a friend of mine: Mr. Question Mark. He's happy to help whenever you have a sentence phrased like a question.)
However, maybe it is good that they fined them nearly a billion. I, too, doubt that that alone will make much of a dent in Microsoft's budget, but maybe it sets a precedent, and other nations may start doing the same. South Korea, for instance, springs to mind. One billion dollar fine might not make much, but if a large enough number other nations start fining Microsoft for anti-trust violations, they might have to do something real about it. Even if these nations are just out for the money, they still need some legal pretext in order to act, so if Microsoft will wish to avoid it, they might actually have to comply with the law or retract from business in those nations.
I know I might just be overly optimistic, but one must keep one's hopes up, right?
Either way, I'm much more optimistic about the "sharing of server protocols" part of the judgment. It would be great being able to use Samba as an AD controller.
Note, though, that it isn't actually code that they have been ordered to release, but rather protocol specifications. Which is, of course, what everyone wants. No article I've read on the subject so far has made any mention of how the specifications need to be licensed, however. If anyone is in the know, please share that information.
Yeah, I found that strange, too. I could more than well understand a ruling static something like ringtones being freely distributable due to being so much shorter and of so much lower quality than the original song, or something like that. But not being a derivative work of the original song? Does Copyright Office actually have some kind of point here that I don't see, or are they just being stupid, or have they been bought by the MAFIAA?
It's obscure because, as far as I know, all the standard syscall implementations on both *nix and NT copy the contents of user-space buffers into kernel space before doing anything at all with them, including validation. From what I can tell from the article, the problem is limited to syscall wrappers, and how often are they even used? Sure, there are several implementations (all whose names I've forgotten), but how many people actually use them outside of doing research on them?
The blurb mentions Anti-Virus software, but since I've never used any AV software (I didn't back in the dark ages when I used Windows, and I certainly haven't since I stopped using Windows), I don't really know how they work. Maybe they, too, use some kind of syscall wrappers to catch viruses. In that case, maybe there's some valid concern that Windows users might be at risk. However, I'd dub that an implementation bug in AV software, and shouldn't be any harder to fix than it is to add detection for new viruses as happens normally anyway.
Either way, should the problem be any harder to fix than just making the syscall wrappers block threads trying to write to the affected memory pages until the syscall has finished executing? In all but the most esoteric situations, I would think such a fix would lead to no problems.
Besides, nothing will really break if you remove ubuntu-standard. That is not advise that I would give. I don't know for sure, but I'm pretty certain that ubuntu-standard is the metapackage the developers use as mechanism for ensuring the new packages are installed when doing a distro-upgrade. If you remove it, I wouldn't bet that distro-upgrading works anymore.
To be honest, the 'everything is a file' thing is the thing that bugs me most about UNIX. In principle, I am in favour of an 'everything is a {something}' interface, but files are a horrible abstraction for persistent data storage, and are much worse for other things. Most things that look like files but aren't have a load of custom ioctls associated with them, and so don't really behave like files. They have a convenient shared namespace, but not a shared interface (sure, you can open and stat them, but if you want to get any real work done it's all ioctl manipulation).
But the namespace part is the whole point of it. Sure, it would be better without the ioctl part, but it's not as if there is such a thing as an interface which can incorporate anything while still being meaningful on its lowest level. I don't even know what you would argue in favor of instead -- some kind of smalltalk-like system where you can send messages instead (for some meaning of "message")? In that case, it would still be equivalent, since any message can be encoded as a standard Unix bytestream.
In fact, I think that, too, is one of the great things with Unix, as long as one manages to avoid ioctls. Not only can anything be encoded as a bytestream, a bytestream is also the only thing which can be handled by anything -- it can be stored on disk, transmitted over a network, input from a keyboard, sent over an RS-232 link, or hexdumped, printed and put on a carrier pigeon, if you fancy that. There may be some parsing involved, indeed, but I cannot think as anything else so universal.
And the original genius of Unix was, of course, to put all these bytestream end-points into one namespace. Sadly, over time that has become more and more diluted, first with the Berkeley sockets API, and then with the sysctl interface. (I get the distinct feeling that there are other examples as well, but, frustratingly, I cannot think of them)
Of course, I don't claim that Unix is the end of all interface abstractions -- I have quite a few ideas of my own, and Ken Thompson has shown his own ideas with Plan9 -- but it is far better than almost anything currently available today, at least. Certainly better than anything used commercially.
Sysctls are nice because they present a single namespace for exposing both text and binary information in the contexts they are most useful.
But then you have two namespaces; one for sysctls, and the other for everything else. Surely, at least you cannot deny that it would be more elegant to make them one? Furthermore, the sysctl namespace follows dissimilar rules -- It has different path conventions. It has no standardized interface for enumerating a directory, getting/setting permissions, and getting other stat() data. You cannot have a sysctl node as your cwd in a process. &c. (Admittedly, procfs in Linux also violates a few useful rules, like the ability to chmod files in/proc/sys and such things, but that can just be considered a simple bug)
You could put all of the sysctls in/sys (or whatever), but then you'd probably want to make them text-based, which would require you to add a load of fscanf things to your C code.
OTOH, a call to atoi() probably takes less than a percent of the time it takes to context-switch into the kernel, so that would probably be the least concern. As for code elegance, everything needed would be to just add an abstraction function to libc for it.
You'd also have the temptation to bloat them up, as happens with Linux, and require more complicated parsing, rather than just a single value in each file.
As for temptations, all you'd have to do is to resist it. I'd have every confidence in the BSD developers to do that. However, I for one wouldn't even be tempted, and to be honest, I don't think most Linux developers are either. I'd guess files like/proc/cpuinfo is just a historical artifact that just can
I was recently reminded of how badly Linux sucks when I went over some old code I'd written to get the CPU name and speed. The FreeBSD and OpenBSD implementations of this code each called a single sysctl for each result. The Linux version had to read/proc/cpuinfo and parse it. While I agree with you that Linux seems almost pathetic compared to BSD when under heavy load, I have to object to that reason for calling the *BSDs superior to Linux. In fact, the sysctl interface is the single most bothering thing about the *BSDs to me. Isn't the treatment of everything as a file the very core of the Unix philosophy? It may be true that files like/proc/cpuinfo could very well be made easier to parse, but I find nothing to complain about with e.g. the/proc/sys/ tree, or, for that matter, sysfs. Requiring a special syscall just to fetch kernel data that could just as well be made available through the file system is, in my mind, just ugly for a Unix system, and I can only imagine that it is done that way for historical reasons.
In almost any other way, however, I would prefer the *BSDs over Linux. I still run Linux, though, but that's mainly because I want to keep running Kerberized NFS.:) When FreeBSD implements that, I may well switch.
Ubuntu installs the package "popularity-contest" by default, which reports every package you're using and how often. That's large scale stealth spying, but it's not proprietary so it should be ok... Yeah, it is installed by default, but during the installation procedure you do get the question of whether you actually want to enable it. It is worth noting that it defaults to "no" if you just click past it.
If the specs are credible enough to create a quality Free driver, then I'll switch to AMD in a heart beat. Yes, me too. I was actually planning to do an upgrade of my box in a little while, for the first time in many years now, and I was sure that I was going to get an nVidia card, but this might turn that decision around completely.
However, I have to wonder -- I really have no idea about ATI GPU parts, but the impression I got is that they are releasing the specs for the new top-of-the-line units, and since I don't even play games, I'm not interested in such things. What I'm interested in is having dual-display, TV output, 2D acceleration and XV working on the budget cards (and without making VGA BIOS calls, thank you very much), but I have yet to hear whether these released specifications will cover enough to create a truly free, fully featured driver for the budget model GPUs.
Also, apart from budget models, how will these specifications apply to older cards? I still have a Radeon 7500 lying in a drawer doing nothing just because I never got the TV output working on it in Linux. As a side story on that one, I even engaged in communications with ATI to try and get some specifications on that card in order to enhance the X driver with TV output support, but even when I managed to get my hands on documentation, it conspicuously excluded any information on the registers controlling the TV output encoder (even though I had explicitly requested that information...). That's when I resigned myself and bought a GeForce 5200 instead.
Slashdot Mirror
In all honesty, what does one do with Visio? I've been wondering for the longest time. I have really only seen Visio on a superficial level, but it didn't seem to be more than a somewhat fancy drawing program with a library of symbols, which made it seem quite a bit like Dia to me (except the library was larger).
However, that Octave gets such a thing wrong is hardly surprising. Octave's strength never was to do arithmetics with large integers. In fact, AFAIK Octave never uses integers at all; I'm pretty sure it always uses floating point numbers, so when doing calculations on such large numbers (55! / (27! * (55 - 27)!)), it is hardly surprising that it truncates the numbers somewhere along the line.
When I calculate the same binomial in Emacs Cals, I get 3824345300380220, which is extremely close to Google Spreadsheet's answer. I cannot really imagine how they manage to add that extra 0.5, though.
No wonder you can't meet any women!
The reason I used the formulation "modem with the modem part" is just because that's one of the comments I got on the project in real life. :)
Just for reference, the reason it was designed that way is because in the beginning of telecommunication, the exchange station would just feed 48 V into a line on which the microphones and speakers of both participating telephones were simply connected in series. It's obviously an extremely simple design; befitting the era, I guess. I don't know how it is done these days, but in the days of old, capacitors and resistors weren't used to cancel out feedback, but rather a very special transformer circuit called a duplex coil. Nowadays, it seems to be hard even to find information on how it was constructed.
You might wonder why I know these things; it is simply because I've been trying to design a "telephone soundcard" (like a modem, but without the modulation/demodulation part). It turns out that it is rather easy to construct a converter from a two-wire circuit to a four-wire circuit using two opamps and five resistors. Of course, that won't make the line unloaded.
Maybe there should be a "3) Profit" in there as well?
That was my first thought as well; I thought they had to be retarded. But then, I did something quite unusual -- I RTFA:d. Here's a quote: In the ad, Virgin Mobile printed one of its campaign slogans, "Dump your pen friend," over Alison's picture.The ad also says "Free text virgin to virgin" at the bottom.
That makes it quite a lot different, in my mind. It's one thing to put a vacation photo or similar up on the Internet under a CC license as to allow people to use it as such: as a vacation photo. It's another thing to take that picture and superimpose some message that you may not at all stand for.I would imagine that if I took a picture of myself in front of my computers and put it under a CC license, and Microsoft then used it in one of their advertising campaigns superimposed with the slogan "Get the Facts" or something like that, then I'd be pretty pissed too.
Furthermore, I just can't help thinking it seems kind of stupid with optical links if they want it to truly take the standard over from USB 2.0. I would think it much harder to produce cheap devices that need to include optical transceivers. One of the great advantages of USB in my mind was always that it's very easy to design "client" devices -- you just hook it into your microcontroller and add a couple of capacitors and resistors. But I don't know, maybe they plan to build the optical transceivers directly into the connector, so that the device designer won't even have to think about it.
Another problem seems to be the connection between the HCI and the actual host interconnect. 4.8 Gbps would require at least two PCIe lanes. I doubt many people will want to waste a 16x PCIe port on their motherboards to connect a USB HCI card, and all too few motherboards seem to come with 4-lane connectors. Sure, that won't be a problem once motherboards start integrated USB 3.0 HCIs, but what about until then?
Yeah, they do, but only on your own side. Commonly, the other side's client will still transcribe your smilies to something much more sinister on their side. It could be argued that that is mostly the problem of the person on the other side, but that isn't entirely true; I often find that the stock smilies used by many IM clients look like something that far from always actually conveys the mood you're trying to set with a certain smiley. But, I digress.
It may not be the answer you'd like, but I'd say that if such an MP3 player does indeed exist, it would probably more or less have to be some kind of PC anyway (otherwise, there'd be no point in even making a "large" one, if one could suffice with a portable MP3 player constantly hooked up to the power jack). So if you're going to get one anyway, why not just resign yourself and use a retired PC? It's not as if it would be more expensive than buying any sort of dedicated, AC-hooked MP3 player anyway.
Speaking of which -- on those pictures, I see no Samsung CPU as the summary stated. The only major Samsung chip I can see is the flash chip.
The actual improvements in NFSv4 include such things as compound calls (which is, on a completely unrelated note, also a new feature in Microsoft's SMB 2.0) which, at least supposedly, improves performance due to network latency. It also included symbolic UID/GID mapping (rather than working with numerical IDs). It also works better through firewalls by using a single TCP connection for everything (although personally, I think the firewall problem should be fixed instead...). While there exists an extension for POSIX APIs for NFSv3, NFSv4 has ACL support on its own, and I think it supports XATTRs as well (though the Linux implementation doesn't yet).
I'm pretty sure it includes other improvements as well, but I cannot remember any others right now. For me, the most important feature of the new protocol as such was the symbolic ID mapping, since it means that I can access my NFS home directories on my laptop without also having to use NIS and other things that wouldn't work when I take the laptop out from my home network.
There have been a number of suggestions to solve it that problem, of course, ranging from adding an extra field for DNS servers in the autoconfig ICMP messages to using well-known unicast addresses for the closest recursive DNS server to using a dedicated protocol just to discover DNS servers. The first and last of those have (rightfully, IMNSHO) been shot down because then one might "just as well" use DHCP, which exists and has a solution ready for the issue at hand. I cannot remember why the unicast suggestions have been rejected, though, and it has been disturbing me, because I think it is the best solution. I really just cannot see the drawbacks to it. I guess there might have been some talk about lack of security in that model, but that's a problem with DNS in general, though. That's why DNSSEC was invented.
Last I looked, the consensus seems to be to use autoconfig for address generation, and then request network information (such as DNS servers) from a link-local DHCPv6 server. When everything comes around, I think that's a rather good solution. Clients can still get whatever non-occupied address they want (which means the privacy extensions will also continue to work), and still get the information they find relevant, and a DHCPv6 server should be easy to implement on a network of any scale.
However, maybe it is good that they fined them nearly a billion. I, too, doubt that that alone will make much of a dent in Microsoft's budget, but maybe it sets a precedent, and other nations may start doing the same. South Korea, for instance, springs to mind. One billion dollar fine might not make much, but if a large enough number other nations start fining Microsoft for anti-trust violations, they might have to do something real about it. Even if these nations are just out for the money, they still need some legal pretext in order to act, so if Microsoft will wish to avoid it, they might actually have to comply with the law or retract from business in those nations.
I know I might just be overly optimistic, but one must keep one's hopes up, right?
Either way, I'm much more optimistic about the "sharing of server protocols" part of the judgment. It would be great being able to use Samba as an AD controller.
Note, though, that it isn't actually code that they have been ordered to release, but rather protocol specifications. Which is, of course, what everyone wants. No article I've read on the subject so far has made any mention of how the specifications need to be licensed, however. If anyone is in the know, please share that information.
Yeah, I found that strange, too. I could more than well understand a ruling static something like ringtones being freely distributable due to being so much shorter and of so much lower quality than the original song, or something like that. But not being a derivative work of the original song? Does Copyright Office actually have some kind of point here that I don't see, or are they just being stupid, or have they been bought by the MAFIAA?
The blurb mentions Anti-Virus software, but since I've never used any AV software (I didn't back in the dark ages when I used Windows, and I certainly haven't since I stopped using Windows), I don't really know how they work. Maybe they, too, use some kind of syscall wrappers to catch viruses. In that case, maybe there's some valid concern that Windows users might be at risk. However, I'd dub that an implementation bug in AV software, and shouldn't be any harder to fix than it is to add detection for new viruses as happens normally anyway.
Either way, should the problem be any harder to fix than just making the syscall wrappers block threads trying to write to the affected memory pages until the syscall has finished executing? In all but the most esoteric situations, I would think such a fix would lead to no problems.
To be honest, the 'everything is a file' thing is the thing that bugs me most about UNIX. In principle, I am in favour of an 'everything is a {something}' interface, but files are a horrible abstraction for persistent data storage, and are much worse for other things. Most things that look like files but aren't have a load of custom ioctls associated with them, and so don't really behave like files. They have a convenient shared namespace, but not a shared interface (sure, you can open and stat them, but if you want to get any real work done it's all ioctl manipulation).
But the namespace part is the whole point of it. Sure, it would be better without the ioctl part, but it's not as if there is such a thing as an interface which can incorporate anything while still being meaningful on its lowest level. I don't even know what you would argue in favor of instead -- some kind of smalltalk-like system where you can send messages instead (for some meaning of "message")? In that case, it would still be equivalent, since any message can be encoded as a standard Unix bytestream.
In fact, I think that, too, is one of the great things with Unix, as long as one manages to avoid ioctls. Not only can anything be encoded as a bytestream, a bytestream is also the only thing which can be handled by anything -- it can be stored on disk, transmitted over a network, input from a keyboard, sent over an RS-232 link, or hexdumped, printed and put on a carrier pigeon, if you fancy that. There may be some parsing involved, indeed, but I cannot think as anything else so universal.
And the original genius of Unix was, of course, to put all these bytestream end-points into one namespace. Sadly, over time that has become more and more diluted, first with the Berkeley sockets API, and then with the sysctl interface. (I get the distinct feeling that there are other examples as well, but, frustratingly, I cannot think of them)
Of course, I don't claim that Unix is the end of all interface abstractions -- I have quite a few ideas of my own, and Ken Thompson has shown his own ideas with Plan9 -- but it is far better than almost anything currently available today, at least. Certainly better than anything used commercially.
Sysctls are nice because they present a single namespace for exposing both text and binary information in the contexts they are most useful.
But then you have two namespaces; one for sysctls, and the other for everything else. Surely, at least you cannot deny that it would be more elegant to make them one? Furthermore, the sysctl namespace follows dissimilar rules -- It has different path conventions. It has no standardized interface for enumerating a directory, getting/setting permissions, and getting other stat() data. You cannot have a sysctl node as your cwd in a process. &c. (Admittedly, procfs in Linux also violates a few useful rules, like the ability to chmod files in /proc/sys and such things, but that can just be considered a simple bug)
You could put all of the sysctls in /sys (or whatever), but then you'd probably want to make them text-based, which would require you to add a load of fscanf things to your C code.
OTOH, a call to atoi() probably takes less than a percent of the time it takes to context-switch into the kernel, so that would probably be the least concern. As for code elegance, everything needed would be to just add an abstraction function to libc for it.
You'd also have the temptation to bloat them up, as happens with Linux, and require more complicated parsing, rather than just a single value in each file.
As for temptations, all you'd have to do is to resist it. I'd have every confidence in the BSD developers to do that. However, I for one wouldn't even be tempted, and to be honest, I don't think most Linux developers are either. I'd guess files like /proc/cpuinfo is just a historical artifact that just can
In almost any other way, however, I would prefer the *BSDs over Linux. I still run Linux, though, but that's mainly because I want to keep running Kerberized NFS. :) When FreeBSD implements that, I may well switch.
Yes, me too. I was actually planning to do an upgrade of my box in a little while, for the first time in many years now, and I was sure that I was going to get an nVidia card, but this might turn that decision around completely.
However, I have to wonder -- I really have no idea about ATI GPU parts, but the impression I got is that they are releasing the specs for the new top-of-the-line units, and since I don't even play games, I'm not interested in such things. What I'm interested in is having dual-display, TV output, 2D acceleration and XV working on the budget cards (and without making VGA BIOS calls, thank you very much), but I have yet to hear whether these released specifications will cover enough to create a truly free, fully featured driver for the budget model GPUs.
Also, apart from budget models, how will these specifications apply to older cards? I still have a Radeon 7500 lying in a drawer doing nothing just because I never got the TV output working on it in Linux. As a side story on that one, I even engaged in communications with ATI to try and get some specifications on that card in order to enhance the X driver with TV output support, but even when I managed to get my hands on documentation, it conspicuously excluded any information on the registers controlling the TV output encoder (even though I had explicitly requested that information...). That's when I resigned myself and bought a GeForce 5200 instead.