Hold your breath for I shall perform a feat rarely seen on Slashdot... I will actually talk about the subject of the article!
Epeg has one purpose, to scale JPEG images very quickly. One of the primary reasons it was created was because of the freedesktop.org thumbnail spec. The spec requires that the thumbnails be stored as PNG's. While experimenting with this, it was found that converting large JPEG's to PNG's was a relatively slow process because of the color space conversions and IDCT. If the spec was extended to allow JPEG thumbnails, then the conversion process can be JPEG to JPEG.
By keeping the formats the same, you can now do the scaling during the jpeg decode (avoid extra pixel traversals scaling the RGB data after it has been decoded), keep JPEG native color space (no YCbCr->RGB conversion, again traversing the pixel data, twice if you go back to non-RGB image data), and reducing the output written to disk in almost every case (because of the end result being a JPEG rather than a PNG).
Overall, it exists because it didn't seem right to not support the most common image format as a thumbnail when it allows for such large speed increases creating the thumbnails and reduced disk space used for meta-data. Just because disks get larger and CPU speeds increase doesn't mean we shouldn't use them wisely, especially when it's less than a days worth of hacking to do so.
I need to correct a couple of things in this post. E17, EWL, and all of the graphical portions of Enlightenment rely on Evas for drawing. Evas is a very nice API for image rendering that supports a variety of backends. It currently has engines for software Xlib, OpenGL on X, the linux framebuffer, and even Cairo. There was a proprietary Windows engine that was not released (BSD licensed library). There is also an abstracted event library called Ecore that performs non-blocking I/O and event processing. EWL currently runs on all target platforms supported by Ecore and Evas, so portability is not a significant problem. If a new platform is added to Ecore and Evas, EWL only needs a few stub functions filled in to handle the different events and to interact with the display.
Sorry Shish, but you're wrong on this one. The ibar, clock, and other gadgets are all drawn on a single virtual root window with evas. The shadow is also only drawn on the root window, not on overlapping windows. Take a look at raster's post to see some of the reasons why this is the case.
Yes, I am one of the more active developers on the enlightenment project at this time.
In all honesty, I would not bother checking the window manager out of CVS, but some of the libraries are worthwhile to look at now. The actual window manager code was more of a test bed to try out a few new ideas. Some of them panned out, others didn't, but the concensus has been to take the good things from it and work it into a new codebase. Much work is going into solidifying the library backends before work on the new window manager gets rolling.
Yes, and in the end, there is a good chance this will be an option for Enlightenment. Raster has been hard at work on an image layout/animation engine for theming borders and backgrounds, and I would be willing to bet once the OpenGL evas backend is in place, there will be an option to use it for animated backgrounds. Borders will most likely be software only until a hardware solution is found that provides increased performance for small drawing areas.
Maybe he did expect it, he didn't mention one way or another before he left. "Some attention" is much different than making it on slashdot, which I think would fall more under the "ass-load of attention" category.:-)
You're right, he is a graphics oriented programmer, and he does know his stuff quite well. My comment regarding configurations was addressing numerous posters asking "did he enable feature X?", "is he using kernel Y?", or "did he install the right driver?", etc.
The point was, he made his testing methods available, if people take issue with them they are free to do something about it. He wants to be proven wrong so he has a good reason to add an Xrender backend to Evas.
The current version of Evas is actually the second iteration. The first version had a backend written for OpenGL, which performed quite well for large drawing areas, but was sluggish with many small areas (bad for window managers). The software engine easily outperformed in those cases, and will be used for the resulting window manager's border drawing.
For now, there is not an OpenGL engine in Evas, because of time constraints. E has a relatively small active development team atm, so it's difficult to say when someone will get around to adding the OpenGL engine. There should be one eventually, all nicely encapsulated except for a couple setup functions.
Normally, he would answer some questions or comments posted about something he has written, but he will be out of town for at least a few days.
I highly doubt he meant for this to get wide-spread exposure beyond developers of Enlightenment or X. Since it has, this is a good opportunity. I'll make this clear for anyone that didn't catch it, raster WANTS XRENDER TO BE FASTER! If there is a way to alter configuration or to recode the benchmark to do so, he wants to know about it.
Rather than posting questions about his configuration (which he can't answer right now), grab the benchmarks that he put up and get better results.
IANAL, but from my understanding, the only major issues here are copyright on specific sections of code and the possible breach of contract by IBM. Copyright does apply to your first case of essentially copying code using different variable/function names, but not the design of the system.
The design of UNIX is not a trade secret, it is broadly published in Operating Systems books, the BSD kernels, and the API component is controlled by standards groups. To win a claim based on design using copyright law, the code would not only have to be similar in function, but nearly identical in form (excluding changed variable names, or other trivial changes), and from what I've seen of Linux and BSD internals, this is not the case.
Besides, broad protection of a design is generally a patent issue, of which SCO has very few, and the original UNIX patents have expired.
Re:stick to e16 for a wm, but e17 has nice stuff
on
State of the E-nion
·
· Score: 1
> ecore: Currently it has basic IPC wrapping, X wrapping, Evas wrapping, job handling...
> I think it's kind of a bad sign when you have to write a wrapper > for your own library to be released with your library, so you can > write your program which depends on... your library.
FYI, evas is has backends for multiple environments, including X11, OpenGL, DirectFB, native FB, Qtopia, and Windows. In order to allow this flexibility, a little setup is required to prepare an area for the evas. The ecore wrapping is just meant to simplify this setup process in X (and possibly other backends, I haven't looked at that portion of ecore). It's really not necessary, but it can make your life a bit easier.
Well, it's good to see that a university is actually doing some pilot programs before jumping into a technology. Unfortunately, I can't say the say the same for my school. The University of Minnesota Duluth College of Science and Engineering will be requiringall incoming freshman to purchase from the university Compaq H3650's. This will be extended to include all students the following year.
This decision had very little input from the current students at the university, and I have yet to hear of any established applications for this technology. For those too lazy to follow the link, here's the purpose as stated by the department:
The purpose of the iPAQ requirement is both to enhance the technological environment of the engineering and computer science classroom and to better prepare UMD graduates to be competitive in the work world. The hand-held or "pocket" pc is truly cutting edge technology. It has very recently and very rapidly become an important tool of practicing professionals in engineering, industry, business, and information technology. It is the expectation of UMD and the College of Science and Engineering that our graduates be among the most prepared and most competitive in this rapidly changing world.
This is an extremely technocratic statement, and does not address any of the actual uses for the technology.
Thank goodness I'm graduating this year...
RbdPngn
This article reminds me a lot of the movie Bulworth. I just saw it last week and I was amazed at the issues it tackled. It takes on issues of corporate control on politics, the problems with a bi-partisan system, the problems with racial discrimination that still occur in our society, and other politically charged topics.
Even though the subjects are quite serious, the movie maintains a lighthearted comical tone throughout. So if you're interested in the issues Katz addresses in this article and you haven't seen this movie, run to your local video store and rent it!
While I agree with both of these comments, from what I read of this book, I don't think this would be the way I would want to learn these concepts. A good book covering generalized OS concepts can be purchased for a little more. A book such as Operating Systems Concepts by Abraham Silberschatz and Peter Baer Galvin teaches them in more depth, and uses examples taken from a variety of OSes (ie. Linux, BSD, Windows NT). One could easily review the source code for Linux (or one of the BSDes) while reading to help understand the actual code. My impression of Linux Core Kernel Commentary was that it was a step-by-step explanation of code. I could see how this could be helpful under certain circumstances, but not in understanding general OS concepts. If the reader does not understand the general concepts, they are less likely to be able to adapt to changes. Also, using the argument that learning one version of the kernel will make a person understand all following versions is an even stronger argument for the online guides. Most of these guides are based on 2.0, but they fulfill a similar role to this book.
I flipped through this book one day, and I must say that it seemed to be a pretty good reference. But I'm not sure if it's worth the money when there are good references online. Also, the book covers one version of the source code. As the kernel source is constantly evolving, it will only remain accurate for a short period of time. Plus, you lose the ability of quickly searching files that is available with most text editors.
Though, if you look at the number of BSD boxes compared to the number of Linux boxes, it seems like a strong showing for Linux.
With that many boxes, there are probably plenty that aren't configured very well. Where there are much fewer BSD boxes, and there's probably a good chance that the sys admins know how to set up there software better.
Well, either way, Open Source is beating the pants off everyone else.;-)
P.S. I like your nickname. DragonBallZ reference right?
Something I find rather disturbing is the fact that all the coverage I've seen of this arrest acts as though the suspect has already been tried and found guilty.
I know the Feds don't make arrests frivilously, but you're still innocent until proven guilty in this country.
The media has pretty much proclaimed the suspect as the great white satan. Even if he is not found guilty at trial, his name has been dragged through the mud. And I'm sure if he's releaseed, the most mention it will get is a little foot-note at the end of the news.
I know that this happens in other trials, but this one seems to be an exagerated case.
Slashdot Mirror
Hold your breath for I shall perform a feat rarely seen on Slashdot... I will actually talk about the subject of the article!
Epeg has one purpose, to scale JPEG images very quickly. One of the primary reasons it was created was because of the freedesktop.org thumbnail spec. The spec requires that the thumbnails be stored as PNG's. While experimenting with this, it was found that converting large JPEG's to PNG's was a relatively slow process because of the color space conversions and IDCT. If the spec was extended to allow JPEG thumbnails, then the conversion process can be JPEG to JPEG.
By keeping the formats the same, you can now do the scaling during the jpeg decode (avoid extra pixel traversals scaling the RGB data after it has been decoded), keep JPEG native color space (no YCbCr->RGB conversion, again traversing the pixel data, twice if you go back to non-RGB image data), and reducing the output written to disk in almost every case (because of the end result being a JPEG rather than a PNG).
Overall, it exists because it didn't seem right to not support the most common image format as a thumbnail when it allows for such large speed increases creating the thumbnails and reduced disk space used for meta-data. Just because disks get larger and CPU speeds increase doesn't mean we shouldn't use them wisely, especially when it's less than a days worth of hacking to do so.
I need to correct a couple of things in this post. E17, EWL, and all of the graphical portions of Enlightenment rely on Evas for drawing. Evas is a very nice API for image rendering that supports a variety of backends. It currently has engines for software Xlib, OpenGL on X, the linux framebuffer, and even Cairo. There was a proprietary Windows engine that was not released (BSD licensed library). There is also an abstracted event library called Ecore that performs non-blocking I/O and event processing. EWL currently runs on all target platforms supported by Ecore and Evas, so portability is not a significant problem. If a new platform is added to Ecore and Evas, EWL only needs a few stub functions filled in to handle the different events and to interact with the display.
Sorry Shish, but you're wrong on this one. The ibar, clock, and other gadgets are all drawn on a single virtual root window with evas. The shadow is also only drawn on the root window, not on overlapping windows. Take a look at raster's post to see some of the reasons why this is the case.
He also gave an interview on Minnesota Public Radio covering similar topics on September 29. Follow the link for a RealMedia archive.
Yes, I am one of the more active developers on the enlightenment project at this time.
In all honesty, I would not bother checking the window manager out of CVS, but some of the libraries are worthwhile to look at now. The actual window manager code was more of a test bed to try out a few new ideas. Some of them panned out, others didn't, but the concensus has been to take the good things from it and work it into a new codebase. Much work is going into solidifying the library backends before work on the new window manager gets rolling.
Yes, and in the end, there is a good chance this will be an option for Enlightenment. Raster has been hard at work on an image layout/animation engine for theming borders and backgrounds, and I would be willing to bet once the OpenGL evas backend is in place, there will be an option to use it for animated backgrounds. Borders will most likely be software only until a hardware solution is found that provides increased performance for small drawing areas.
Maybe he did expect it, he didn't mention one way or another before he left. "Some attention" is much different than making it on slashdot, which I think would fall more under the "ass-load of attention" category. :-)
You're right, he is a graphics oriented programmer, and he does know his stuff quite well. My comment regarding configurations was addressing numerous posters asking "did he enable feature X?", "is he using kernel Y?", or "did he install the right driver?", etc.
The point was, he made his testing methods available, if people take issue with them they are free to do something about it. He wants to be proven wrong so he has a good reason to add an Xrender backend to Evas.
Yes, and yes. :-)
The current version of Evas is actually the second iteration. The first version had a backend written for OpenGL, which performed quite well for large drawing areas, but was sluggish with many small areas (bad for window managers). The software engine easily outperformed in those cases, and will be used for the resulting window manager's border drawing.
For now, there is not an OpenGL engine in Evas, because of time constraints. E has a relatively small active development team atm, so it's difficult to say when someone will get around to adding the OpenGL engine. There should be one eventually, all nicely encapsulated except for a couple setup functions.
Normally, he would answer some questions or comments posted about something he has written, but he will be out of town for at least a few days.
I highly doubt he meant for this to get wide-spread exposure beyond developers of Enlightenment or X. Since it has, this is a good opportunity. I'll make this clear for anyone that didn't catch it, raster WANTS XRENDER TO BE FASTER! If there is a way to alter configuration or to recode the benchmark to do so, he wants to know about it.
Rather than posting questions about his configuration (which he can't answer right now), grab the benchmarks that he put up and get better results.
Now back to your regularly scheduled trolling...
IANAL, but from my understanding, the only major issues here are copyright on specific sections of code and the possible breach of contract by IBM. Copyright does apply to your first case of essentially copying code using different variable/function names, but not the design of the system.
The design of UNIX is not a trade secret, it is broadly published in Operating Systems books, the BSD kernels, and the API component is controlled by standards groups. To win a claim based on design using copyright law, the code would not only have to be similar in function, but nearly identical in form (excluding changed variable names, or other trivial changes), and from what I've seen of Linux and BSD internals, this is not the case.
Besides, broad protection of a design is generally a patent issue, of which SCO has very few, and the original UNIX patents have expired.
> ecore: Currently it has basic IPC wrapping, X wrapping, Evas wrapping, job handling ...
> I think it's kind of a bad sign when you have to write a wrapper
> for your own library to be released with your library, so you can
> write your program which depends on... your library.
FYI, evas is has backends for multiple environments, including X11, OpenGL, DirectFB, native FB, Qtopia, and Windows. In order to allow this flexibility, a little setup is required to prepare an area for the evas. The ecore wrapping is just meant to simplify this setup process in X (and possibly other backends, I haven't looked at that portion of ecore). It's really not necessary, but it can make your life a bit easier.
Well, it's good to see that a university is actually doing some pilot programs before jumping into a technology. Unfortunately, I can't say the say the same for my school. The University of Minnesota Duluth College of Science and Engineering will be requiring all incoming freshman to purchase from the university Compaq H3650's. This will be extended to include all students the following year.
This decision had very little input from the current students at the university, and I have yet to hear of any established applications for this technology. For those too lazy to follow the link, here's the purpose as stated by the department:
The purpose of the iPAQ requirement is both to enhance the technological environment of the engineering and computer science classroom and to better prepare UMD graduates to be competitive in the work world. The hand-held or "pocket" pc is truly cutting edge technology. It has very recently and very rapidly become an important tool of practicing professionals in engineering, industry, business, and information technology. It is the expectation of UMD and the College of Science and Engineering that our graduates be among the most prepared and most competitive in this rapidly changing world.
This is an extremely technocratic statement, and does not address any of the actual uses for the technology.
Thank goodness I'm graduating this year...
RbdPngn
This article reminds me a lot of the movie Bulworth. I just saw it last week and I was amazed at the issues it tackled. It takes on issues of corporate control on politics, the problems with a bi-partisan system, the problems with racial discrimination that still occur in our society, and other politically charged topics.
Even though the subjects are quite serious, the movie maintains a lighthearted comical tone throughout. So if you're interested in the issues Katz addresses in this article and you haven't seen this movie, run to your local video store and rent it!
While I agree with both of these comments, from what I read of this book, I don't think this would be the way I would want to learn these concepts. A good book covering generalized OS concepts can be purchased for a little more. A book such as Operating Systems Concepts by Abraham Silberschatz and Peter Baer Galvin teaches them in more depth, and uses examples taken from a variety of OSes (ie. Linux, BSD, Windows NT). One could easily review the source code for Linux (or one of the BSDes) while reading to help understand the actual code. My impression of Linux Core Kernel Commentary was that it was a step-by-step explanation of code. I could see how this could be helpful under certain circumstances, but not in understanding general OS concepts. If the reader does not understand the general concepts, they are less likely to be able to adapt to changes. Also, using the argument that learning one version of the kernel will make a person understand all following versions is an even stronger argument for the online guides. Most of these guides are based on 2.0, but they fulfill a similar role to this book.
I flipped through this book one day, and I must say that it seemed to be a pretty good reference. But I'm not sure if it's worth the money when there are good references online. Also, the book covers one version of the source code. As the kernel source is constantly evolving, it will only remain accurate for a short period of time. Plus, you lose the ability of quickly searching files that is available with most text editors.
Though, if you look at the number of BSD boxes compared to the number of Linux boxes, it seems like a strong showing for Linux.
;-)
With that many boxes, there are probably plenty that aren't configured very well. Where there are much fewer BSD boxes, and there's probably a good chance that the sys admins know how to set up there software better.
Well, either way, Open Source is beating the pants off everyone else.
P.S. I like your nickname. DragonBallZ reference right?
Something I find rather disturbing is the fact that all the coverage I've seen of this arrest acts as though the suspect has already been tried and found guilty.
I know the Feds don't make arrests frivilously, but you're still innocent until proven guilty in this country.
The media has pretty much proclaimed the suspect as the great white satan. Even if he is not found guilty at trial, his name has been dragged through the mud. And I'm sure if he's releaseed, the most mention it will get is a little foot-note at the end of the news.
I know that this happens in other trials, but this one seems to be an exagerated case.