I'm surprized safari scored this bad. Anyway, Browsers are likely the most complex software to properly benchmark. Writing a tangible and useful conclusion from all those charts and numbers is nearly impossible.
I have coded a few large javascript/DOM-intensive applications and my overall feeling is that chrome rocks both on compliance and speed. It also seems much better on garbage collection than FF3, which stills badly suffers from unreleased memory. My experience with safari on those applications is good overall; faster than FF3 and a little slower than chrome.
You can map special keyboard key sto mark begining or end of a block, and a few others keys to save/load/delete the block.
INSERT => mark begnining of block END => mark end of block (and yand the block) F2 => save block into a buffer file F3 => insert buffer file at current position DELETE => remove block
You need to type CRTL-V before hitting the function key to get its escape sequence properly set in the file. You also can use special names for function keys ( I believe?) instead of storing your terminal-dependant sequences. ^M is a single character (hex code 0x0d) which you can type using CTRL-V followed by the ENTER key.
To be more precise, I suppose you meant that there are still many cross-browser incompatibilities with DOM, CSS and HTML, not on the javascript language itself, isn't it ?
I am experiencing this memory problem all the time, and it has a direct link with the javascript interpreter. I might be wrong, but I think the problem has been widely analyzed and documented. And partly fixed on FF3.
A simple test that works for me consist of using the phpmyadmin program on FF/ubuntu: after one hour or so, my FF process starts lagging a lot and need a restart, reaching approx 500MB memory usage. This stinks memory fragmentation and leak.
I'm also seeing this problem with my own "web2" applications. I've spent some time to run various experiments to see how this memory problem occurs, but I could not detect a "pattern". Google map API, for example, added a "cleanup" callback that breaks circular references in their javascript data. This dramatically improved one of my app, which previously was barely usable after viewing just a dozen pages containing gmap data.
I thought the plan was to export democracy, free speech, human rights and other such goodies... oh boy, was I wrong!
I'm sorry to tell you this, but If you ever believed the plan was about bringing democracy, you're either naive or very undocumented. I'm assuming #2. The good thing is that it can be fixed; all it takes from you is a tendency to sckepticism when it comes to governement propaganda, and a taste to read foreign press. Most of what you know today about Irak was largely forecasted and documented back in 2003.
Western governments practices stink. A lot. It goes far beyond average citizen awareness, and that's part of the problem.
"How about every bill being publicly posted without alteration for 90 days before any voting is allowed"
Aside the practical aspects, I doubt it would change anything. The case for Irak was sold through disinformation, not lack of information. What might have prevented this could be (1) listening to the rest of the world, which was largely against this insanity (for good and bad reasons), (2) having effective accountability, which obviously is not working here.
Jeez, we have great slashdot here: take the most controversial words out of a 4 pages article, and makes it the title, even though they represent nothing. TFA mostly focus on giving UNA a great exposure, and as such, it is interesting, but all of this has really little to do with "open source killed something".
As much as I like dia and kivio, naming them "visio clones" is at best far fetched; If you're using visio seriously, they're not really playing on the same level yet.
The only difference, but that seems to be an important one for some people, is that the fax machine prints status data with the date, time and remote fax number. That's strange to me, but this has greater value than email envelope, even though both can be easily forged.
Don't expect them to adopt some new technology like silverlight on every single public site they posess in a heartbeat
Certainely not. But between your figure and no exposure at all (almost), there is some room, and it looks odd that did not really start some sort of significant promotion for their technology (unless I missed it).
Moreover, just suggesting that they would re-write an existing portal (that may not even really need SL technology) simply because a new technology came out makes no sense
They did that "non-sense" (in a technical point of view) in the past. Just look at the hotmail migration (attempt) on windows server for example. If you want your technology to get exposure, you need to show it in action on realife applications. Microsoft has the horsepower to do that sort of things very quickly and deeply, to the contrary of many others.
It looks strange to me because I've little doubt that the client-rich application's future is closer to FLEX/SL than the present web "standards".
I am somehow puzzled by the lack of presence of real life (read: useful) silverlight applets. I would expect microsoft to start using it extensively at this point, because we're hearing about silverlight for quite some time now.
As a développer, I was really hoping some good news when they started this stuff. I was looking forward to get a truly appropriate alternative for the web craps on the rich client front, and this is really disapointing so far. It is going to take much more than a "mine sweeper", "page turner", etc. to get me on board, and nothing seems to emerge as far as I know. Unless I'm really not up to date, flex seems really a lot more advanced.
Anyway, I might simply be plain wrong with expectation of this kind.
You may be right, but most AV are hooked at filesystem level anyway (i.e. when you writes or run an exe file). I wonder if/how this hook would replace this filesystem control in a better way... Might be good for CLAM which does not have on access scanning.
No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)
I am using BSD in production environments for years; almost everything I'm installing IS bsd based. I was wanting journaled filesystem since forever, just because I'm sick of fsck, and yes, linux has been a lot better on this for many many years (I also work a lot with linux). Softupdates are truly great, but they don't cover the check part.
The block level journal with GEOM works fine and certainly has a lot of technical vertues, granted. However, it sucks, alot, in some case such as mine. It has tons of side effects I had to fight against, not mentioning the enormous amount of disk it takes which prevent journaled filesystems under ~4Gb (I'm working with embeded small sized systems). As someone who had to write automatic installers/cloner for bsd and linux, I spent an enormous amount of time to make it working reliably on journaled geom while it barely took a few mn to turn ext2 into ext3. As for its usefulness, I'm not totally certain that journaled FAT is something I should care about, but it's just me.
To the web developers reading this: Wouldn't it be nice to be able to write totally standards-compliant markup and code and not have to taint it with all the hacks that are practically a necessity these days?
It would be great, sure, but it would only remove some of the surface pain and frustration. I am a programmer with over 15 years of experience in many language/environments. I have used and created all sort of complex products to implement GUIs. Web is so far the most frustrating and time burner environment.
The problem is not limited to standard compliance: the standards (some of it) are part of the problem: they're not designed to offer what a lot of people are trying to do those days: running rich applications on a browser. We have to do all sort of contorsions to make "simple things" working; gluing together frameworks, libraries, workaround, hacks, etc etc. And the end result is a software that takes hundred of MBs to run (slowly) on the client.
There are really nice things though. JavaScript *as a language* is great (though perfectible) for client side coding. Its syntax could be more strict, but I can live with that. Having a tree representation of the GUI is fine too; that's how windowing works forever afterall (it's just that the DOM is no a great implementation).
This whole thing does not work well, we need a different rich client approach. That's why I'm giving some hope to things like silverlight, but this hope is... tiny.
Whatever the merit of this python gui, comparing it to time machine is far fetched, to say the least...
I think you're right: the value of time machine lies in its GUI. Much more than in its underlying file copy techniques. Like in any serious backup tool, the interface is _the_ key element. Obviously, data needs to be saved reliably somewhere, but that's something we can do in various ways for a long time.
An efficient backup/restore GUI is hard to do. This is what Apple has done beautifuly here, and this is what bring the tool in the average user's hands. This is new.
Ok, I admit not having read TFA entirely. I stopped there: "table: both can be improved". How is that for a comment ? Word is miles ahead when it comes to table, really. As much as I like OO, there is no question whatsoever here. I wonder what kind of testing would lead to such a useless conclusion. As for the "drawing tools", writer likely never write a real life document with vectorial images to give a "Tie" verdict.
On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).
Web development adds specific complexity to "classical" dev platforms. You have to deal with 4 dialects at minimum: html, css, javascript, and the one that really run on the server. Worse than that: you are usually given development tools that makes possible (and encourage) to mix these languages endlessly in a single piece of code.
Web dev best practice #1 to me is: do _NOT_ mix this stuff; keep them well apart as much as you can, otherwise you endup with spaghetty-write-only-code than even you won't be able to read in a few month from its writing (I'm assuming the programmer care about that). Mixing them will also guarantee that you won't be able to reuse your code efficiently.
I totally second you here. The complexity is not on the same magnitude, like it or not. Yes, there are plenty of bundles that make apache easier to setup, but as soon as you want something that goes beyond the coverage of those packages, you endup writing apache configuration files. IIS can definitely do more in this aspect.
I always thought what really lack apache is some meta-configuration tool: a program that turns some plain-english configuration data (which could fit well in a GUI, if possible) and generates apache directives. Apache config is brilliant and powerful, but does not meet average user's expertise.
I have hacked such tool myself when my servers configurations became too big for my own brain. It works really well and makes you focus on high level features more than details. In other words, you can do much more with less headache.
Maybe something like that already exists; it wasn't the case last time I checked.
There are known knowns. These are things we know that we know. There are known unkowns. That is to say, there are things we know we don't know. But, there are also unknown unknowns. These are things we don't know we don't know.
Slashdot Mirror
Ahhhh, that explains. That's like comparing apples and cats.
I'm surprized safari scored this bad. Anyway, Browsers are likely the most complex software to properly benchmark. Writing a tangible and useful conclusion from all those charts and numbers is nearly impossible.
I have coded a few large javascript/DOM-intensive applications and my overall feeling is that chrome rocks both on compliance and speed. It also seems much better on garbage collection than FF3, which stills badly suffers from unreleased memory. My experience with safari on those applications is good overall; faster than FF3 and a little slower than chrome.
You can map special keyboard key sto mark begining or end of a block, and a few others keys to save/load/delete the block.
INSERT => mark begnining of block
END => mark end of block (and yand the block)
F2 => save block into a buffer file
F3 => insert buffer file at current position
DELETE => remove block
Here is what I do in .exrc to map those keys:
map ^[OH mx :'x,'y w! /tmp/bufferfile^M :r /tmp/bufferfile^M :'x,'y del^M
map ^[0F my:'x,'y y^M
map ^[OQ
map ^[OR
map ^[[3~
You need to type CRTL-V before hitting the function key to get its escape sequence properly set in the file. You also can use special names for function keys ( I believe?) instead of storing your terminal-dependant sequences. ^M is a single character (hex code 0x0d) which you can type using CTRL-V followed by the ENTER key.
cd /somewhere &
> a good long look at why the US was being attacked by these people
"These people" ? I think the proper response should have started by: _who_ exactly were these people.
To be more precise, I suppose you meant that there are still many cross-browser incompatibilities with DOM, CSS and HTML, not on the javascript language itself, isn't it ?
I am experiencing this memory problem all the time, and it has a direct link with the javascript interpreter. I might be wrong, but I think the problem has been widely analyzed and documented. And partly fixed on FF3.
A simple test that works for me consist of using the phpmyadmin program on FF/ubuntu: after one hour or so, my FF process starts lagging a lot and need a restart, reaching approx 500MB memory usage. This stinks memory fragmentation and leak.
I'm also seeing this problem with my own "web2" applications. I've spent some time to run various experiments to see how this memory problem occurs, but I could not detect a "pattern". Google map API, for example, added a "cleanup" callback that breaks circular references in their javascript data. This dramatically improved one of my app, which previously was barely usable after viewing just a dozen pages containing gmap data.
I thought the plan was to export democracy, free speech, human rights and other such goodies ... oh boy, was I wrong!
I'm sorry to tell you this, but If you ever believed the plan was about bringing democracy, you're either naive or very undocumented. I'm assuming #2. The good thing is that it can be fixed; all it takes from you is a tendency to sckepticism when it comes to governement propaganda, and a taste to read foreign press. Most of what you know today about Irak was largely forecasted and documented back in 2003.
Western governments practices stink. A lot. It goes far beyond average citizen awareness, and that's part of the problem.
"How about every bill being publicly posted without alteration for 90 days before any voting is allowed"
Aside the practical aspects, I doubt it would change anything. The case for Irak was sold through disinformation, not lack of information. What might have prevented this could be (1) listening to the rest of the world, which was largely against this insanity (for good and bad reasons), (2) having effective accountability, which obviously is not working here.
Jeez, we have great slashdot here: take the most controversial words out of a 4 pages article, and makes it the title, even though they represent nothing. TFA mostly focus on giving UNA a great exposure, and as such, it is interesting, but all of this has really little to do with "open source killed something".
As much as I like dia and kivio, naming them "visio clones" is at best far fetched; If you're using visio seriously, they're not really playing on the same level yet.
The only difference, but that seems to be an important one for some people, is that the fax machine prints status data with the date, time and remote fax number. That's strange to me, but this has greater value than email envelope, even though both can be easily forged.
Don't expect them to adopt some new technology like silverlight on every single public site they posess in a heartbeat
Certainely not. But between your figure and no exposure at all (almost), there is some room, and it looks odd that did not really start some sort of significant promotion for their technology (unless I missed it).
Moreover, just suggesting that they would re-write an existing portal (that may not even really need SL technology) simply because a new technology came out makes no sense
They did that "non-sense" (in a technical point of view) in the past. Just look at the hotmail migration (attempt) on windows server for example. If you want your technology to get exposure, you need to show it in action on realife applications. Microsoft has the horsepower to do that sort of things very quickly and deeply, to the contrary of many others.
It looks strange to me because I've little doubt that the client-rich application's future is closer to FLEX/SL than the present web "standards".
I am somehow puzzled by the lack of presence of real life (read: useful) silverlight applets. I would expect microsoft to start using it extensively at this point, because we're hearing about silverlight for quite some time now.
As a développer, I was really hoping some good news when they started this stuff. I was looking forward to get a truly appropriate alternative for the web craps on the rich client front, and this is really disapointing so far. It is going to take much more than a "mine sweeper", "page turner", etc. to get me on board, and nothing seems to emerge as far as I know. Unless I'm really not up to date, flex seems really a lot more advanced.
Anyway, I might simply be plain wrong with expectation of this kind.
char *ptr=malloc(1099511627776);
memset(ptr,1,1099511627776);
You may be right, but most AV are hooked at filesystem level anyway (i.e. when you writes or run an exe file). I wonder if/how this hook would replace this filesystem control in a better way... Might be good for CLAM which does not have on access scanning.
No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)
I am using BSD in production environments for years; almost everything I'm installing IS bsd based. I was wanting journaled filesystem since forever, just because I'm sick of fsck, and yes, linux has been a lot better on this for many many years (I also work a lot with linux). Softupdates are truly great, but they don't cover the check part.
The block level journal with GEOM works fine and certainly has a lot of technical vertues, granted. However, it sucks, alot, in some case such as mine. It has tons of side effects I had to fight against, not mentioning the enormous amount of disk it takes which prevent journaled filesystems under ~4Gb (I'm working with embeded small sized systems). As someone who had to write automatic installers/cloner for bsd and linux, I spent an enormous amount of time to make it working reliably on journaled geom while it barely took a few mn to turn ext2 into ext3.
As for its usefulness, I'm not totally certain that journaled FAT is something I should care about, but it's just me.
April 1st already ?
To the web developers reading this: Wouldn't it be nice to be able to write totally standards-compliant markup and code and not have to taint it with all the hacks that are practically a necessity these days?
... tiny.
It would be great, sure, but it would only remove some of the surface pain and frustration. I am a programmer with over 15 years of experience in many language/environments. I have used and created all sort of complex products to implement GUIs. Web is so far the most frustrating and time burner environment.
The problem is not limited to standard compliance: the standards (some of it) are part of the problem: they're not designed to offer what a lot of people are trying to do those days: running rich applications on a browser. We have to do all sort of contorsions to make "simple things" working; gluing together frameworks, libraries, workaround, hacks, etc etc. And the end result is a software that takes hundred of MBs to run (slowly) on the client.
There are really nice things though. JavaScript *as a language* is great (though perfectible) for client side coding. Its syntax could be more strict, but I can live with that. Having a tree representation of the GUI is fine too; that's how windowing works forever afterall (it's just that the DOM is no a great implementation).
This whole thing does not work well, we need a different rich client approach. That's why I'm giving some hope to things like silverlight, but this hope is
> If no one ever reinvented the wheel, we'd be rolling around on stone tires now.
The problem is that php reinvented the stone tires !
Whatever the merit of this python gui, comparing it to time machine is far fetched, to say the least...
I think you're right: the value of time machine lies in its GUI. Much more than in its underlying file copy techniques. Like in any serious backup tool, the interface is _the_ key element. Obviously, data needs to be saved reliably somewhere, but that's something we can do in various ways for a long time.
An efficient backup/restore GUI is hard to do. This is what Apple has done beautifuly here, and this is what bring the tool in the average user's hands. This is new.
Ok, I admit not having read TFA entirely. I stopped there: "table: both can be improved". How is that for a comment ? Word is miles ahead when it comes to table, really. As much as I like OO, there is no question whatsoever here. I wonder what kind of testing would lead to such a useless conclusion. As for the "drawing tools", writer likely never write a real life document with vectorial images to give a "Tie" verdict.
On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).
Web development adds specific complexity to "classical" dev platforms. You have to deal with 4 dialects at minimum: html, css, javascript, and the one that really run on the server. Worse than that: you are usually given development tools that makes possible (and encourage) to mix these languages endlessly in a single piece of code.
Web dev best practice #1 to me is: do _NOT_ mix this stuff; keep them well apart as much as you can, otherwise you endup with spaghetty-write-only-code than even you won't be able to read in a few month from its writing (I'm assuming the programmer care about that). Mixing them will also guarantee that you won't be able to reuse your code efficiently.
I totally second you here. The complexity is not on the same magnitude, like it or not. Yes, there are plenty of bundles that make apache easier to setup, but as soon as you want something that goes beyond the coverage of those packages, you endup writing apache configuration files. IIS can definitely do more in this aspect.
I always thought what really lack apache is some meta-configuration tool: a program that turns some plain-english configuration data (which could fit well in a GUI, if possible) and generates apache directives. Apache config is brilliant and powerful, but does not meet average user's expertise.
I have hacked such tool myself when my servers configurations became too big for my own brain. It works really well and makes you focus on high level features more than details. In other words, you can do much more with less headache.
Maybe something like that already exists; it wasn't the case last time I checked.
There are known knowns. These are things we know that we know. There are known unkowns. That is to say, there are things we know we don't know. But, there are also unknown unknowns. These are things we don't know we don't know.