I disagree with you here. While being a Linux user, when I first discovered Slashdot (a whhiiiillle ago), I created its bookmark in the "News" directory, not "Linux" directory, 'cause it was a place where you could talk of any OS, as long as what you had to say was reasonable (and on topic). The place changed a lot since then, and I miss the "o' time":(
I trust the Seti organization, and I have downloaded and run their client for some time now. That's not "their" client, SETI@Home is an independent project
This is not an assumption, when you design an interface it is very important to follow the rules of the GUI environment you are using to reduce confusion and lower the time needed to master new apps.
If you have specific needs, create additional controls (aka widgets), but give old controls a new behavior is bad ergonomic style by any metric.
I'm not affiliated with them, but sites like http://www.iarchitect.com are really interesting if you're interested in GUI ergonomy...
It plays VCDs almost perfectly fine for me (23 to 24 frames/s with good quality, so it drops one or two frames per second on my P200MMX, seldom noticeable)
MMmh, I wrote a (cooperative) multitasking Minitel server with TPW 1.0 and M$ Windows 3.1 a while ago... I was using a 80286 16MHz and 4Mb memory at that time! (2Mb was a bit uncomfortable for devel, but worked). Sure, each new version (TPW 1.5, BPW 7.0, Delphi...) was more bloated than the previous one, but they definitely could do wonderful tools for not-so-powerful boxes at that time.
Dunno if I would go back to any mono-platform devel tool, though.
They comment on how this new standard will speed up transfers, but does anyone have an idea of how much? Considering many consumers are still limited by bandwidth on their end, it generally won't get faster for them, but mostly more efficent transfers before it ends up with them. Correct? Or am I just entirely missing the point. =] Yes:) It's not about bandwidth, it's about latency (mostly, let's explain); Each connection needs to be initialized (the tcp "3 way handshake" is time consuming), then "tcp slow start" gets in the way, and in the end small objects (pages or small gfx) never reach the full speed of your connection. Browsers try to hide the problem, opening many connections at a time so that connection establishments can be overlayed with transfers, and that transfer speeds sum up. The point of HTTP/1.1 is to transfer many objects back-to-back using a single tcp connection, so you pay connection time and slow start only once for all those objects. Browsers will still be allowed to open many connections at once, but only up to two per server, to be nice with others:)
Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? The domain of the URL you requested will be sent in the HTTP request. It is already done right now (with HTTP/1.0 ?), but will be _required_ by HTTP/1.1.
What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert. That's up to the server.
But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one. You're correct, and that's why it needs to be specified in the HTTP request headers.
Btw, how new is all this ? Last time I checked, Apache 1.3.x is already HTTP/1.1 compliant, no ?
Plain fork() is really fast on Linux. I'm not sure vfork() syscall was added for performance reason, but rather because of people requests (ease the porting for apps that use vfork(), and simple enough to implement that Linus bothered implementing it:) ). I could be wrong, I saw the discussing some months ago...
>Most websites use some form of database stuff, therefore it makes more sense to use linux for those sites (or so it does to me). "database stuff" usually don't fork either, for performance reasons. Either database files are opened by some database library (that can stay in memory as long as the client code is), or, client-server style, the queries are sent to a database daemon that is also persistent (multiforked with processes pool or multithreaded, shouldn't matter).
I think that the figures are so close that you will choose FreeBSD or Linux over the other depending on others criteria (apps, available hardware, staff knowledge,...)
True, being from Bordeaux I'd rather keep Greenwich Meridian (0 deg 44 min west... It's almost Bordeaux Meridian, as you can see on the map;) ) More seriously, this looks like history; Never heard anyone complaining of Greenwich Meridian in my life...
They're lots of authoritative sources on the subject available online; I came across the Coffee and Caffeine FAQ a while ago, and just found http://www.coffeescience.org/, to give only examples...
If you sum up all those very specialized lists, that gives a rather good figure (and things often "gets done" outside of newsgroups and mailing lists anyway, whereas public forums are where wishes belongs best). So ?
Re:Does reiserfs address other ext2 problems?
on
Reiserfs Released
·
· Score: 1
I don't think either belong to the filesystem layer, what's wrong with encryption (loop) layer and raid ?
Re:Does reiserfs address other ext2 problems?
on
Reiserfs Released
·
· Score: 1
Read linux-kernel mailing list, you'll find a big discussion on the subject.
Last time it was discussed (that is, just some months ago), the answer was : in (almost ?) all cases where someone could wish for user-defined attributes, they can be emulated with directories, and directories have the advantage of not breaking existing applications. That's another reason to use reiserfs btw.
The fact remains, if the free operating systems are so horribly bad, why is it so many private users and corporations that use them FEEL like they are more stable and better performing? Oh well, just my righteous two cents. Because it doesn't match our day-to-day experience ? Since I moved our accounting database from local box (PII NT workstation) to the server (P233MMX Linux), the guy on the NT workstation said he observed an *increased* speed. And yes, the files are shared thru Samba (I know, some client-server architecture would be better, but hey, the stuff is not exactly OSS:( ). Agreed, that's a small LAN with few clients (mix of NT workstation and Win 9x boxes), so even if I believe the benchmark figures are for real, I can't reproduce the tests. But I can say that in my real life case, Linux is a much better solution that NT. I feel like this benchmark is totally irrelevant because it doesn't grab the cases when Linux is used (at least right now). It mostly shows that NT features that Linux lacks, like 0-copy networking, are nice to have sometimes, that is mostly during benchmarks.
>And overheads for processes as opposed to threads is always much higher. not in Linux case, fork() is just a special case of clone().
>Especially when you have to start communicating across processes. Not the case to serve static pages, right ? Not to mention IPCs aren't for free between threads either (locking).
>Threading isn't just a nasty hack to get speed, it's there cause it's a good design - why do you think a mutithreaded ip stack is going to be incorporated into linux soon? What's the difference between processes and threads ? Share of memory space, no more, no less. And no better, no worse. Linux IP stack won't get "multithreaded" as you say, it will be de-serialized. And if you don't see the difference, get a book on "standard" (not microkernel one) Unix architecture.
>And I wasn't saying that Linux IS guilty, I was saying that it's more likely linux would be guilty of leaving requests idle than what you said about NT (eg. don't make stupid claims about NT). Same thing about Linux, I don't think the choice of processes/threads influence the equitability of the scheduling more than the scheduler design (hint). NT and Linux have different schedulers, but I don't think either is significantly "unequitable", right.
Sorry, I don't agree. I read linux-kernel mailing list for a while, and even if many people have strong opinions there (and not everyone having the same opinions either) the amount of flame per-se is rather low (that is, name-calling, and opinions thrown without any sort of backing). It is well known that Linus is not particularly fond of microkernel architecture, yet I don't remember that particular quote. Could you give us some link (if possible with some context, Linus has been known to be quoted out-of-context many times, with bad results when combined with his tongue-in-cheek kind of humor...)
At that time, the true web standards were immature, and couldn't make pages look like their creators wanted. HTML was a very simple markup tool. That was the aim of the HTML, yes. I won't call all the additions that came after "maturation", but "bastardization". Wysiwyg HMTL is a bad joke. Pages didn't look like their creators wanted. Pages don't look like their creators wanted. Pages won't look like their creators wanted. The idea is a big flaw as long as we don't all have the same browser in the same resolution, etc.
That is why HTML as a simple markup language is neat : That's the Right Thing(Tm) to do.
Regardless of whether or not you think this was a bad thing, it's what led to the web as it is: early web browsers like Netscape, and, later, Internet Explorer, extended HTML and related standards to make it do what they wanted. Somewhere along those lines, though, the World Wide Web Consortium (w3c) got on its feet and started creating new markup languages (such as CSS and XML) and adding abilities to other languages (HTML 4.0).
The "look" has been the problem of the browser alone from the very start, and I remember having seen the concept of "style sheets" on the w3c site for years... It was not formalized yet, but it could have been way faster if software companies showed more interest that they did.
Instead, they choosed not to implement the "clean solution" at that time, and it is a shame.
Slashdot Mirror
I disagree with you here. :(
While being a Linux user, when I first discovered Slashdot (a whhiiiillle ago), I created its bookmark in the "News" directory, not "Linux" directory, 'cause it was a place where you could talk of any OS, as long as what you had to say was reasonable (and on topic).
The place changed a lot since then, and I miss the "o' time"
So humour doesn't exist in your reality ?
That would be sad.
It's rather well explain ed on the SETI@Home web site, just look more closely.
I trust the Seti organization, and I have downloaded and run their client for some time now.
That's not "their" client, SETI@Home is an independent project
Metaphors are neat. You can "prove" about anything using metaphors. Maybe that's why they're so useful in politics.
If you have specific needs, create additional controls (aka widgets), but give old controls a new behavior is bad ergonomic style by any metric.
I'm not affiliated with them, but sites like http://www.iarchitect.com are really interesting if you're interested in GUI ergonomy...
It plays VCDs almost perfectly fine for me (23 to 24 frames/s with good quality, so it drops one or two frames per second on my P200MMX, seldom noticeable)
Sure, each new version (TPW 1.5, BPW 7.0, Delphi...) was more bloated than the previous one, but they definitely could do wonderful tools for not-so-powerful boxes at that time.
Dunno if I would go back to any mono-platform devel tool, though.
Yes
Browsers try to hide the problem, opening many connections at a time so that connection establishments can be overlayed with transfers, and that transfer speeds sum up.
The point of HTTP/1.1 is to transfer many objects back-to-back using a single tcp connection, so you pay connection time and slow start only once for all those objects. Browsers will still be allowed to open many connections at once, but only up to two per server, to be nice with others
Also, does anyone know how it's going to allow multi-domains on single IPs? Almost sounds like a redirect of some complex (or lack of compexity) sort. Mayhaps the daemon will take the domain requested, and devide from there? The domain of the URL you requested will be sent in the HTTP request. It is already done right now (with HTTP/1.0 ?), but will be _required_ by HTTP/1.1.
What if you just typed in the IP address? Will it default to some domain? I find this pretty confusing, but I'm no expert.
That's up to the server.
But sense connections are made to IPs, not really domains (Or so I thought), I'm just slightly lost on this one.
You're correct, and that's why it needs to be specified in the HTTP request headers.
Btw, how new is all this ? Last time I checked, Apache 1.3.x is already HTTP/1.1 compliant, no ?
Plain fork() is really fast on Linux. :) ).
I'm not sure vfork() syscall was added for performance reason, but rather because of people requests (ease the porting for apps that use vfork(), and simple enough to implement that Linus bothered implementing it
I could be wrong, I saw the discussing some months ago...
"database stuff" usually don't fork either, for performance reasons.
Either database files are opened by some database library (that can stay in memory as long as the client code is), or, client-server style, the queries are sent to a database daemon that is also persistent (multiforked with processes pool or multithreaded, shouldn't matter).
I think that the figures are so close that you will choose FreeBSD or Linux over the other depending on others criteria (apps, available hardware, staff knowledge, ...)
True, being from Bordeaux I'd rather keep Greenwich Meridian (0 deg 44 min west... It's almost Bordeaux Meridian, as you can see on the map ;) )
More seriously, this looks like history; Never heard anyone complaining of Greenwich Meridian in my life...
They're lots of authoritative sources on the subject available online; I came across the Coffee and Caffeine FAQ a while ago, and just found http://www.coffeescience.org/, to give only examples...
If you sum up all those very specialized lists, that gives a rather good figure (and things often "gets done" outside of newsgroups and mailing lists anyway, whereas public forums are where wishes belongs best). So ?
I don't think either belong to the filesystem layer, what's wrong with encryption (loop) layer and raid ?
Last time it was discussed (that is, just some months ago), the answer was : in (almost ?) all cases where someone could wish for user-defined attributes, they can be emulated with directories, and directories have the advantage of not breaking existing applications.
That's another reason to use reiserfs btw.
BTW, can you compile Lame without GTK libs ?
command line compressor is all what I'm interested about...
The fact remains, if the free operating systems are so horribly bad, why is it so many private users and corporations that use them FEEL like they are more stable and better performing? Oh well, just my righteous two cents. :( ).
Because it doesn't match our day-to-day experience ?
Since I moved our accounting database from local box (PII NT workstation) to the server (P233MMX Linux), the guy on the NT workstation said he observed an *increased* speed. And yes, the files are shared thru Samba (I know, some client-server architecture would be better, but hey, the stuff is not exactly OSS
Agreed, that's a small LAN with few clients (mix of NT workstation and Win 9x boxes), so even if I believe the benchmark figures are for real, I can't reproduce the tests.
But I can say that in my real life case, Linux is a much better solution that NT. I feel like this benchmark is totally irrelevant because it doesn't grab the cases when Linux is used (at least right now). It mostly shows that NT features that Linux lacks, like 0-copy networking, are nice to have sometimes, that is mostly during benchmarks.
Not to mention NT has way to go before scaling against *all* commercial Unixen (many benchmarks around, pick yours)...
not in Linux case, fork() is just a special case of clone().
>Especially when you have to start communicating across processes.
Not the case to serve static pages, right ? Not to mention IPCs aren't for free between threads either (locking).
>Threading isn't just a nasty hack to get speed, it's there cause it's a good design - why do you think a mutithreaded ip stack is going to be incorporated into linux soon?
What's the difference between processes and threads ? Share of memory space, no more, no less. And no better, no worse. Linux IP stack won't get "multithreaded" as you say, it will be de-serialized. And if you don't see the difference, get a book on "standard" (not microkernel one) Unix architecture.
>And I wasn't saying that Linux IS guilty, I was saying that it's more likely linux would be guilty of leaving requests idle than what you said about NT (eg. don't make stupid claims about NT).
Same thing about Linux, I don't think the choice of processes/threads influence the equitability of the scheduling more than the scheduler design (hint). NT and Linux have different schedulers, but I don't think either is significantly "unequitable", right.
Sorry, I don't agree. I read linux-kernel mailing list for a while, and even if many people have strong opinions there (and not everyone having the same opinions either) the amount of flame per-se is rather low (that is, name-calling, and opinions thrown without any sort of backing).
It is well known that Linus is not particularly fond of microkernel architecture, yet I don't remember that particular quote. Could you give us some link (if possible with some context, Linus has been known to be quoted out-of-context many times, with bad results when combined with his tongue-in-cheek kind of humor...)
Looks like the definition of load balancing to me...
Guess he meant MPn+1, not MP4 specifically. ;)
Or if he did, he shouldn't
That was the aim of the HTML, yes. I won't call all the additions that came after "maturation", but "bastardization". Wysiwyg HMTL is a bad joke. Pages didn't look like their creators wanted. Pages don't look like their creators wanted. Pages won't look like their creators wanted. The idea is a big flaw as long as we don't all have the same browser in the same resolution, etc.
That is why HTML as a simple markup language is neat : That's the Right Thing(Tm) to do.
Regardless of whether or not you think this was a bad thing, it's what led to the web as it is: early web browsers like Netscape, and, later, Internet Explorer, extended HTML and related standards to make it do what they wanted.
Somewhere along those lines, though, the World Wide Web Consortium (w3c) got on its feet and started creating new markup languages (such as CSS and XML) and adding abilities to other languages (HTML 4.0).
The "look" has been the problem of the browser alone from the very start, and I remember having seen the concept of "style sheets" on the w3c site for years... It was not formalized yet, but it could have been way faster if software companies showed more interest that they did.
Instead, they choosed not to implement the "clean solution" at that time, and it is a shame.
That shit leaks memory like crazy... :((