Well duh.

If only I could become a bank to borrow at the FED counter...

Those people who are 35 and up now were teenagers 25 years ago, that's 1986 and earlier. In 1986 and before, the time in which the people who are at least 35 years old and today were young teenagers beginning to think about which career path to choose. And in 1986, computers were, well, mostly boring, and definitely not something to make good money in.

So, how many teenagers do you think choose a career path into something that looks boring and not making much money?

MSDOS and it's FAT filesystem (and their predecessors) had it too, and called them 'file extensions', They uses things like 'exe' for the apps, 'ico' for the related icons, 'jpg' for the photo, 'txt' for the comments, 'doc' for the related documents, 'bat' for task descriptions, etc, etc.

They just aren't used like that much...

And instead of using what already exists, it's much better to reinvent the wheel and give it a whole new name.

(/sarcasm, or not?)

I've had one of those black rectangle flatscreen mobile devices to play videos for the little one quite a while now, and it was on the market before the iPad. It has been mistaken for an iPad frequently, even though it doesn't even have a touchscreen.

Here is a picture, 'looks like an iPad', or, because it predates it, 'an iPad looks like this':

http://www.technotalks.com/reviews/aluratek-preps-in-cinepal-hi-def-portable-media-player/

I'm not saying it's an iPad, but it looks like one and it's a battery powered thing with a big screen you can carry around and it has screens with icons, menus, and stuff, it even plays videos and music.

And in the article you link to, a commenter also linked to this interesting image: http://i.imgur.com/3AlUc.jpg

That looks pretty helpful, almost like a synaptic for windows. Does it also get rid of the 'I have an update please do another cycle of clicks now' popups that so many windows applications have?

"there would still be some murmurings about whether or not that teachers having a direct, unfiltered, (and most of all) unmonitored access to their child outside of class is a good or bad thing."

Good point, but who says that the social networks can't make something where the parents of a child, as known to the network, can choose to want to review and filter that communication, like moderators, as it is on done certain forums?

I bet a lot of parents would love to have the option to 'approve/disapprove' certail levels of contact to their children from 'outsiders'. Nana can talk directly, others get moderated by mom, dad, or nana ;-), and all postings with links to websites get moderated too...

Social Networks are not just for 'buddies', they are a way for people to communicate, and apparently quite a popular one. I can see it useful for kids to ask their teacher questions on-line, or for a teacher to notify or remind their students of something. Yes, there are other things for that such as forums, email, and chat, but there are social networks for that too, and (gasp) some people like them (probably because it both integrates a lot of the on-line methods and communication and removes things such as needing to update a contact because they switched email addresses). Don't get me wrong, I mostly use email myself, but that might just be 'legacy' or 'habit'.

Now, many students wouldn't want their teacher to see everything they do/say on the social networks, but that's what google plus has those 'circles' for. You can even let people you don't like be 'in' your social network, you just put them in a 'circle' that doesn't see anything (and vice-versa, the on-line version of fake friendlyness).

For completenes, the xkcd link:

http://xkcd.com/849/

"If only it was engineered like a modern TV to burn out in a year or two"

So was most stuff in the 80s. The TV just got lucky.

At any point in time T, there will always be peope with a still working product of T-30 years wondering why they nowadays "don't make products like that anymore", ignoring how many products from time T-30 years have broken down many many years ago and are long forgotten.

The 'democracy of open source' is that if someone wants to make it, he can, and if it's better than the other thing out there (or the only thing), people will start to use it.

X has had the advantage of being the only display server out there (no I'm not counting fbdev, libsvga etc). Well, with Wayland it will have some serious competition. May the best display server win!

Wayland not having a network transport is like a new cadillac model not being sold in Texas. You know, it won't take a miracle to make it happen.

I've used X since the dark ages myself, but that doesn't mean something new can't be better, and I do know X has its limitations.

What you're looking for i 'strlcpy()' (or on windows maybe 'strncpy_s()'). BSD has strlcpy(), I don't know why glibc (Linux) doesn't have it by default. Actually, I do sort of know: The glibc project leader doesn't like it: http://sources.redhat.com/ml/libc-alpha/2002-01/msg00002.html

Ulrich left it out because he either doesn't like the (BSD) people who came up with strlcpy() (http://www.gratisoft.us/todd/papers/strlcpy.html), or it is what he implies, that he is convinced it encourages lazy programming and causes unexpected failure modes if the programmer forgets that strlcpy() can truncate a string (well he literally says something else, but if he literally means what he says then he just plainly doesn't understand where source strings can come from in the real world).

Besides the fact that strlcpy() has a return value that indicates truncation, he (incorrectly) assumes that ignored truncation can only be bad. I say incorrectly, because there are plenty of cases where a string truncation by strlcpy() is no problem. One important one of them is when the source string is only too long for the buffer if it is either erroneous (and a truncated version of the string is not more problematic later on), or it is specially crafted to try to cause a buffer overflow.... Honestly, I think the missing strlcpy() in glibc is more about personalities than anything else. Oh well...

The irony is that, as a result, some (many?) programmers are now using strncpy() and assuming it does the same thing as strlcpy(), causing more problems than strlcpy() even could have caused in Ulrich's imagination.

The (in case of overflow) not NUL-terminating of strncpy() means the destination is not guaranteed a string. It clearly was not meant to have a string as destination, but just a buffer (that's what the man page says too btw). It's padding with zeros to prevent 'leakage' of previous data in the destination, in case later the destination buffer is forwarded/stored as a whole (not as a string).

I think the main problem with that funtion is its name, it does not do what the name implies. A better name would be memstrcpy(dst,src,count), because it really is a memcopy where the source is a string and the destination is a buffer (it will never read past the end of the source string but always write the entire destination buffer).

I wonder how many people don't have a clue about this. For example, even "{char buf[10]; strncpy(buf,something,9);}" is still not safe, because buf[9] is uninitialized and therefore not guaranteed to be NUL... If you want to use strncpy() and the destination buffer is later treated as a string, you really have to make sure yourself that the last char in your buffer is NUL. When you do use strncpy(), you can check afterwards if the string did fit (it's going to be NUL if it did, not NUL if it didn't), and take appropriate action... But that's a lot of code if you just want a string copy with length truncation, aka strlcpy()...

Sigh? So you don't think it's a big deal that for example for a strcat() of two 100 bytes you now need to copy _both_ strings, because the length field at the beginning now takes up more space, requiring the first string to be moved? How is that efficient?

C doesn't _require_ you to use NUL terminated strings, you can do whatever you feel is cute. A 'char *' is nothing but a pointer, which you can use as a string, but you don't have to, nor the reverse. If you like prefixing a string with a length (vlc coded or not) in your code, you can feel free do to so... Or use C++ and use std::string, because many (all?) implementations of it store the size separately. And yes, std::string has a "max_size()"...

If you don't use NUL terminated octet strings, you just won't be able to easily use many C libraries, because the rest of the world uses NUL terminated strings. And the reason for that is not a 'mistake', the author is wrong.

Get a DVD with the video to bring home? Or a VHS tape? You don't need broadband to watch a video, you know.