I'm sick of trailers and video clips being released in Real, QuickTime, and M$ formats. You would think that from a purely cost/licensing perspective, site owners would want to use a very open and well-defined standard that would reach all platforms (like MPEG)? It just doesn't make sense.
I'd imagine that the bandwidth charges would vastly outweigh the patent/license charges for streaming video.
Maybe when the video version of Ogg Vorgis is available that will change... but unlike Music all the main Video players are written by people pushing a particular proprietry std. (so uptake on support for a free codec would be much less IMO).
Yes, slightly misleading IMO, the LSB currently says you can only have 1 dependancy, on the LSB itself, so presumably he meant "if they followed the guidelines provided by the LSB, you would not have dependancies". That's one way to solve the problem. It's not a very good way though.
Is that even possible with rpm? I didn't think it was posible to turn off autodetection of libc etc.
Of course, even if you do, then whne you compile something on 8.0 with glibc updates it won't work on a system without those updates.
The nice (if obvious) tool for XML is the parser. XML is specified so that any computer science undergrad could write one in a couple weeks.
hahahahahaha. If by "XML" you mean, something with < and > encoded element names and a small ammount of & "character references". Then, yeh, an ok programer could write something passable in a week or two. However XML isn't even remotely this nice, indeed a wc -l *.c for libxml-2.4.23 is 118,775.
But yes, the useful thing about XML isn't XML itself, but the network effects of everyone using it... much like the internet itself.
Bollocks, and double bollocks. If you run unstable (which despite the name is actually very stable 99% of the time) you get most of the latest software, and no depenedency hell.
That's just not true, unstable really is unstable and not only that but debian doesn't provide security guarantees for anything but stable so using anything else is a major cavet-emptor. But that's not such a big problem because noone but insane people can install debian anyway:).
Apt-get is nice for installing things, as is up2date.
And you just cannot beat stable for a server, which doesn't need the latest whizz bang Desktop.
Or you could just use a 2 year old red hat, and get bascially the same software versions:p.
But seriously, the distinction between a server and a desktop is meaningless... my home desktop runs dhcp, dns, smtp and web proxy servers and an apt-get rpm archive. Some of that software I want to be "stable" like the dhcp server, as I don't really use much more than the basics... but I dont want it to break. However some of that I want to be the version that was released recently because I want feature X that came out then.
Debian really fails here.
Yes, apt exists for rpm, but its not just that which make Debian so appealing. But I really have to laugh when I see all these people complaining about how upgrading their systems screws things up. I've been updating (thats update, not this wipe and reinstall nonsense) Debian constantly for 2 years and I've rarely had a problem with it.
On the other hand, I've ugraded from 7.2 to 7.3 to 8.0 and not had a problem. And I upgraded from potato to woddy, and my diald setup ate itself.
Plus debian don't don't do security errata for the kernel... so I think I'm still running 2.4.10 or something equally recent.
Hows things btw Nev? Didn't know you posted on here;)
P.S. C sucks, C++ rules!;)
I don't much... and std. C++ doesn't even exist, so I can only presume you mean gcc-2.95.x C++ which us non-debian people haven't had to use this millenium:):p.
However, some data types lend themselves to it. Ever notice how often file pointers have the name fptr?
Sure, but that isn't really the type, it's a description of what the variable does (it points somewhere in a file). The same way unix file descriptors are often named "fd" (and yes an fd does allow you to do a lot more with it than an fp/fptr)... the type is int but anyone who encodes that into the name is on some serious drugs, IMO.
Linux is also missing kernel implementations of many POSIX 1003.2 features, including all asynchronous I/O functions and realtime signal queues.
Red Hat has been shipping kernel based disk AIO for over a year now. Realtime signal signals queues have been there since 2.4.x... which is what over 2 years old?
Well, how else do you propose to test for buffer overflows?
Don't have staticly sized buffers.
There are more than a few string libraries for C, and amazingly there is a direct correlation between those servers that use one and those that are secure. Then again nsd doesn't seem to have that many static buffers, and UDP servers can get away with this a lot more than most... and it only has one call to strncpy() (which looks dodgey -- but is in the config parser)... well it's not like it can be much worse than bind.
That's just not true. Soft updates works by ordering writes so that the metadata is always in a consistent state. This has the effect of also keeping the data in a consistent state, since data sits in the to-be-ordered queue right along with the metadata.
wrong, if you write to the middle of a file then both UFS+SU and a metadata-only journal won't keep the data consistent in a crash (Ie. you can have some old data and some new data).
If you have a real journal (Ie. data=journal in ext3) then you get consistent data writes too, which is very different. There are other ways to achieve the same thing (WAFL, the unfinished Tux filesystem for Linux) you appear to be correct that JFS only supports a metadata journal.
That is the problem. Even if the programmer has a clue, there are so many ways that it can be accidentally misused that it's not even funny.
I have never seen goto misused by someone with a clue (assuming we discount them trying to make spagetti for a contest or whatever). Sure it's possible to bounce around a function with goto, in the same way it's possible to name all your functions after simpsons/star trek characters... but noone sane does that.
It's not that you can't simulate closures and continuations with C, it's just that it is a very error-prone method.
You don't write good C by pretending it's LISP , and you don't write good LISP by pretending it's C.
C does have some obvious major faults, but most of them are to do with the standard library and can be replaced.
You can create a non-local exit with a goto in C, and you can do it in a very readable way. C also doesn't have any other way to express a non-local exit that is as readable. Therefore I submit that, for C, challenging non use of goto with the non-local exit paper is valid.
Also lot of people, my self included, tend to use goto in C for error recovery... as there is no usful alternative. That doesn't mean that goto and error recovery are the same thing. But it does mean I should be able to argue that using a goto for error recovery in C is good. The only reason I didn't was because I didn't have a paper saying that -- and the guy I responded to seemed more likely to respond to papers than real life (which isn't a compliment).
The problem with Goto is that it has no structure whatsoever, and therefore is susceptible to many, many abuses.
Sure it has no inherent structure, but that supposes that the programmer has no clue. And if you suppose that nothing will help you. LISP and Haskell are only saved here because hardly any good programers use it, and almost zero amatures (which is probably a bad word for them, but is the best I can think of atm.).
2) Lisp is not the same as functional programming.
I never said it was, the original poster said that Languages such as LISP sovled a major source of bugs (variable assignment). He also implied that it was functional. And to be fair not many people would care that it isn't, it's too scarey on it's own nevermind something like Miranda.
Changing the variable (object) value is another source of common mistakes, which must be eliminated. It's solved in Functional Programming
Really, so lisp doesn't have variable Eh? I bet that's news to a lot of people. Haskell and prolog have no variables, IIRC... but that gets even further from mainstream, and requires a way of thinking about constants so that they become variables.
Back at the ranch, JWZ felt that it would have be far easier to pound out the last few details in "Lesstif" and link off of that. The Lesstif people were very close to binary compatibility with version 1 of Motif.
They were going for Source compatability binary compatability was never a real goal.
You also missed out on one of the biggest fuckups, ESR goes into netscape to speak with everyone and they ask him do we release a working netscape, or one that we've put a lot of time into and think will be releasable soon showing yet again his stunning lack of clue he gets them to dump 10s of thousands of lines of non-working development level code that doesn't help anyone for years.
There is a problem, symbol versioning is the official answer but has many issues so people don't use it, it's really to do with ancient linking semantics but the maintainers aren't interesting in changing it. No way out.
Symbol versioning isn't the only solution, sure you can fork the libraries and add symbol versioning and hope the distributions pick it up (or wait for upstream to use it, which isn't going to happen that quickly).
However you can also provide/opt/autopackage/lib/ with local versions of libraries. Just choose the most popular distributions and provide the libraries for all the others to be binary compatible with it.
Or you could just compile things on more than one machine type... having the infrastructure to do this wouldn't be a couple of lines script... but it isn't speech recognition either.
There is a problem, symbol versioning is the official answer but has many issues so people don't use it, it's really to do with ancient linking semantics but the maintainers aren't interesting in changing it. No way out.
Symbol versioning isn't the only solution, sure you can fork the libraries and add symbol versioning and hope the distributions pick it up (or wait for upstream to use it, which isn't going to happen that quickly)... but you can also provide/opt/autopackage/lib/ with local versions of libraries. Just choose the most popular distributions and provide the libraries for all the others to be binary compatible with it.
Or you could just compile things on more than one machine type... having the infrastructure to do this wouldn't be a couple of lines script... but it isn't speech recognition either.
here's no reason why 99% of open source projects actually need to market themselves - they don't need to make money,
While the dict definition of "Marketing" is all about making money, this isn't what most people are using the term to meanin the OSS world, having no users and/or help. I'd say there are four things you want to market for....
Get users, it's much easier to work on something that people are using than working on something that noone else is using.
Get developers, getting help for some problem you want/need solved is a big thing
Getting feedback, it's very helpful to have external auditing of your code, or I compiled your program on blahSystem and this is what happened, or even just getting comments from people who've done similar things.
Getting recognition, after all that works it's nice to get the warm fuzzies:)
...you admit to 2 (and I know I've given you 3) and I'll bet a lot of money you want 1 and 4 as well. As for other people just look at http://freshmeat.net or http://www.gnu.org/directory these are basically simple marketing tools, and a lot of people are using them (I know I am for http://www.and.org/vstr:).
By answering three simple questions, the Creative Commons web application selects an appropriate license for you.
That's the problem, the OpenSource world is all about everyone else. It almost doesn't matter how good your code is, if you aren't using a license I've heard of and understand then I'm not going to bother looking at/using your code.
Here's the simple answer:
Do you want anyone to do anything with the code... choose MIT
Do you want anyone to be able to use it, but any changes to the code to be freely available Choose LGPL
Do you want everything that uses your code to be freely available Choose GPL
In theory you can substitute public domain for the first option, but in reality this is very murky... and you're probably better off just BSD/LGPL dual licensing.
Remeber you're trying to get technical people to use your product, we are coders, not lawyers.
Please direct me to the user(s) that claimed that being able to format your hard disk by visiting a website [extremetech.com] is a feature, and not a bug. I'd like to introduce them to my friend, Mr. Aluminum Bat.
Some of the idea's aren't bad (and those have been done before), but mostly it's just another simple dynamic string library in C.
As for efficency...
t_strconcat() is one function that I also copied from GLIB. It's a bit dangerous though, the terminating NULL is too easy to forget. I've been thinking about removing it entirely, but it's much more efficient than t_strdup_printf() so I haven't yet had the heart:)
...this pretty much speaks for itself. Why Is strconcat() so efficient compared to just doing strcat() multiple times? Because you've got a model for representing the data that has ZERO metadata, and a model for storing the data that requires you to reallocate bits of memory all the time.
Assuming you can just disacount all this overhead by using memory pools, is a simplistic outlook (for instance even if you waste gobs of memory so you don't have to call malloc that much you'll still need to do copies all the time)
There are more than a few much better string libraries out there for C. Probably the best for an IMAP server is probably Vstr as that was deigned to work well in an I/O context (For instance it doesn't need strconcat() like calls in the API because doing repeat adds is just as fast).
This will never be an acceptable solution until
distributions can support it out of the box.
I agree with this, but due to the patenting of QT5 even if someone reverse engineered the format and wrote a decoder in C it wouldn't be supportable by US based Linux distributions anytime this decade.
So, in a very real way this is as good as it's going to get anytime soon.
I don't really follow hurd development (or FreeDOS, which is about as relevant)... however it sounds like what you are saying is that read()/write() syncronisation with the VM isn't done automatically. So every "translator" has to implement VM syncronisation code ? That's just sad, as the only reason to even look at hurd is so you can try out translators... but it looks like you have to write a mini OS so do one.
And this kind of cache management is horribly hard in a monolithic kernel for a start. Look how long 2.4 took before the VM behaviour was considered decent (2.4.16 iirc). A decently fast distributed one is even worse to design.
That's very different, you are just talking about VM syncronisation which has been on Linux since at least 2.0.x (maybe even the start). Ie. mmap() and read()/write().
The VM changes in 2.4.x were mainly for speed and extreme overload cases.
Slashdot Mirror
I'd imagine that the bandwidth charges would vastly outweigh the patent/license charges for streaming video.
Maybe when the video version of Ogg Vorgis is available that will change ... but unlike Music all the main Video players are written by people pushing a particular proprietry std. (so uptake on support for a free codec would be much less IMO).
Don't have staticly sized buffers.
There are more than a few string libraries for C, and amazingly there is a direct correlation between those servers that use one and those that are secure. Then again nsd doesn't seem to have that many static buffers, and UDP servers can get away with this a lot more than most ... and it only has one call to strncpy() (which looks dodgey -- but is in the config parser) ... well it's not like it can be much worse than bind.
wrong, if you write to the middle of a file then both UFS+SU and a metadata-only journal won't keep the data consistent in a crash (Ie. you can have some old data and some new data).
If you have a real journal (Ie. data=journal in ext3) then you get consistent data writes too, which is very different. There are other ways to achieve the same thing (WAFL, the unfinished Tux filesystem for Linux) you appear to be correct that JFS only supports a metadata journal.
The main reference is... http://www.cs.ucsb.edu/~jzhou/security/overflow.ht ml
I have never seen goto misused by someone with a clue (assuming we discount them trying to make spagetti for a contest or whatever). Sure it's possible to bounce around a function with goto, in the same way it's possible to name all your functions after simpsons/star trek characters ... but noone sane does that.
You don't write good C by pretending it's LISP , and you don't write good LISP by pretending it's C.
C does have some obvious major faults, but most of them are to do with the standard library and can be replaced.
You can create a non-local exit with a goto in C, and you can do it in a very readable way. C also doesn't have any other way to express a non-local exit that is as readable. Therefore I submit that, for C, challenging non use of goto with the non-local exit paper is valid.
Also lot of people, my self included, tend to use goto in C for error recovery ... as there is no usful alternative. That doesn't mean that goto and error recovery are the same thing. But it does mean I should be able to argue that using a goto for error recovery in C is good. The only reason I didn't was because I didn't have a paper saying that -- and the guy I responded to seemed more likely to respond to papers than real life (which isn't a compliment).
Sure it has no inherent structure, but that supposes that the programmer has no clue. And if you suppose that nothing will help you. LISP and Haskell are only saved here because hardly any good programers use it, and almost zero amatures (which is probably a bad word for them, but is the best I can think of atm.). I never said it was, the original poster said that Languages such as LISP sovled a major source of bugs (variable assignment). He also implied that it was functional. And to be fair not many people would care that it isn't, it's too scarey on it's own nevermind something like Miranda.They were going for Source compatability binary compatability was never a real goal.
You also missed out on one of the biggest fuckups, ESR goes into netscape to speak with everyone and they ask him do we release a working netscape, or one that we've put a lot of time into and think will be releasable soon showing yet again his stunning lack of clue he gets them to dump 10s of thousands of lines of non-working development level code that doesn't help anyone for years.
Symbol versioning isn't the only solution, sure you can fork the libraries and add symbol versioning and hope the distributions pick it up (or wait for upstream to use it, which isn't going to happen that quickly).
However you can also provide /opt/autopackage/lib/ with local versions of libraries. Just choose the most popular distributions and provide the libraries for all the others to be binary compatible with it.
Or you could just compile things on more than one machine type ... having the infrastructure to do this wouldn't be a couple of lines script ... but it isn't speech recognition either.
Sorry for the non-previewed version .. ack
That's the problem, the OpenSource world is all about everyone else. It almost doesn't matter how good your code is, if you aren't using a license I've heard of and understand then I'm not going to bother looking at/using your code.
Here's the simple answer:
In theory you can substitute public domain for the first option, but in reality this is very murky ... and you're probably better off just BSD/LGPL dual licensing.
Remeber you're trying to get technical people to use your product, we are coders, not lawyers.
The slashdot author is called Michael Sims The CEO of LGP is called Michael Simms.
Being two different people, the conspiracy theories kind of fall flat on their face.
Probably referring to valgrind which is nice, and is both better in some respects and worse in others (than purify).
Some of the idea's aren't bad (and those have been done before), but mostly it's just another simple dynamic string library in C.
As for efficency...
...this pretty much speaks for itself. Why Is strconcat() so efficient compared to just doing strcat() multiple times? Because you've got a model for representing the data that has ZERO metadata, and a model for storing the data that requires you to reallocate bits of memory all the time.
Assuming you can just disacount all this overhead by using memory pools, is a simplistic outlook (for instance even if you waste gobs of memory so you don't have to call malloc that much you'll still need to do copies all the time)
There are more than a few much better string libraries out there for C. Probably the best for an IMAP server is probably Vstr as that was deigned to work well in an I/O context (For instance it doesn't need strconcat() like calls in the API because doing repeat adds is just as fast).
I agree with this, but due to the patenting of QT5 even if someone reverse engineered the format and wrote a decoder in C it wouldn't be supportable by US based Linux distributions anytime this decade.
So, in a very real way this is as good as it's going to get anytime soon.