I'm sorry, this sounds like a poor rationalization for lack of useful functionality. By this logic, you should crash the program without warning whenever invalid input is detected - it could be an attack since no program should ever provide invalid input to a function. In real life, programs have tons of bugs and diagnostic messages are hugely useful in identifying and then fixing them. Especially since the vast majority of programs are not used in a context where an attack can occur.
A 'paranoid' mode with this behavior may make sense for some people. Most people, especially those in the process of developing the software, would prefer diagnostics when things go wrong.
I disagree. There is a big difference between invalid input to a function (eg trying to convert "abc" to an integer) and a memory corruption bug. In the former case, you can return an error to the caller, and if they were written with enough attention to detail, they can fix the problem and move on, or ask the user for actually valid input, or whatever followup action may be appropriate.
In the case of a memory corruption bug, there is no way to correct the problem and move on. By the time you detect the problem, you're already hosed. You can't even rely on the fact that the program accurately knows what it was in the middle of trying to do. I think crashing is absolutely appropriate here. And if you want to debug it, then attach a debugging to the program or the resulting core dump -- all the same information you would have gotten from printed diagnostics can be found (albeit with more effort). But trying to diagnose a memory corruption bug after the fact like this is the hard way to do it anyway. You really want to catch the corruption as it happens, and the are much better tools for this (valgrind, etc).
This list is probably not absolutely 100% complete, but it should be pretty close:
A number of header files defining system call numbers, and structures for interfacing with the kernel. Musl does not require or use the linux kernel headers, so these definitions must be provided by the port itself.
Assembly code for making system calls. There's an inline function version, an implementation of the variadic syscall(2) function, and a version for system calls that made as part of functions defined to be cancellation points
The main _start entry point, which just needs to align the stack as appropriate for the target ABI and call __libc_start_main
A few atomic primitives, probably written in assembly, but some architectures require calling into a kernel helper to implement these
Assembly implementations of setjmp/longjmp
Assembly to query/poke at the floating point state, for fenv support
Assembly for returning from a signal
Assembly for a couple threading things (getting/setting the thread pointer, terminating the calling thread)
A couple specific system calls. Clone requires an assembly version. A couple architectures return the result of the pipe syscall via registers, which also requires an assembly implementation on those architectures.
A little code to handle the few dynamic relocation types particular to the architecture (which are likely to be identical to those used by other architectures, just with different numbers)
Optionally, optimized assembly versions for some math functions, memcpy, and such
putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.
Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.
The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.
Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.
There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.
You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.
One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.
The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.
Take a look at their page on bugs found while developing musl, and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".
ARM can be configured to run as either little or big endian. Instructions are always stored in memory in little endian, but not necessarily so for data. Little endian is more common, but the ARM processor in the Wii, for example, is big endian.
"Freedom of speech" only applies to Government's interference in forms of speech. [...]
No. I keep seeing this repeated, but it's absolutely not true. Constitutionally-protected free speech only applies to the government's interference in forms of speech. [...]
Look at the post he was replying to:
I'm usually against listening to any far winged nut job, but this is freedom of expression which falls under the first amendment. [...]
Sentex wasn't explicit about it, but in context it's obvious that he was talking about constitutionally-protected free speech.
Javascript, maybe. I don't have much experience with it, so I can't comment.
But I have to disagree with HTML. HTML is not programming. Seriously, making a simple webpage in HTML is like typing a document in Word, except typing <b>text</b> instead of hitting the bold button on the toolbar. If that's programming, then typing up a paper for high school English class is too.
HTML _can_ lead into Javascript, PHP, and other facets of web programming. But it's not programming in itself, and if the goal is to introduce him to programming, making him learn HTML before he can start learning programming seems like the wrong way to go about it.
I haven't looked at the official changelog or the code yet, but I'm just as confused as you about that item. Moreso perhaps, as I have used IPv4 over firewire with two linux machines before. That was probably 5 years ago or so.
Merely resaving an image with a higher quality setting won't magically repopulate the high frequency coefficients, so I think this will still work in that case. Of course, if the image has gone through any sort of filtering or modification before being resaved, then all bets are off. But that's also beyond the scope of what the original poster asked for - he wanted a way to detect JPEG compression artifacts, not any extra filtering that might have also been applied.
JPEG works by breaking the image into 8x8 blocks and doing a two dimensional discrete cosine transform on each of the color planes for each block. At this point, no information is lost (except possibly by some slight inaccuracies converting from RGB to YUV as is used in JPEG). The step where the artifacts are introduced is in quantizing the coefficients. High frequency coefficients are considered less important and are quantized more than low frequency coefficients. The level of quantization is raised across the board to increase the level of compression.
Now, how is this useful? The reason heavily quantizing results in higher compression is because the coefficients get smaller. In fact, many become zero, which is particularly good for compression - and the high frequency coefficients in particular tend towards zero. So partially decode the images and look at the DCT coefficients. The image with more high frequency coefficients which are zero is likely the lower quality one.
So, that will show you which parts differ. How do you tell which is higher quality? Sure, you can probably do it by eye. But it sounds like the poster wants a fully automated method.
No it doesn't. This method has another problem (see my replies to it), but other than that, it could work. He's suggesting that to each copy of the image, you look at the difference between that copy and a blurred version of it. This will give you an idea of how sharp that copy is. And since JPEG throws out high frequency information first, resulting in blurring, it would appear at first glance that the sharper image should be the higher quality one.
As I said in another comment though, JPEG operates on blocks, and especially at very low qualities, you get sharp edges between each block. So the assumption that sharp image == high quality is not really valid.
Also, JPEG works on blocks. While it's true that JPEG gets rid of high frequency details first (and thus results in blurring), this is only useful within each block. You can have high contrast areas at the edge of each block, and this is actually often some of the most annoying artifacting in images compressed at very low quality. So just because it has sharp edges doesn't mean it's high quality.
Even faster is look at the DCT coefficients in the file itself. Doesn't even require decoding - JPEG compression works by quantizing the coefficients more heavily for higher compression rates, and particularly for the high frequency coefficients. If more high frequency coefficients are zero, it's been quantized more heavily, and is lower quality.
Now, it's not foolproof. If one copy went through some intermediate processing (color dithering or something) before the final JPEG version was saved, it may have lost quality in places not accounted for by this method. Comparing quality of two differently-sized images is also not as straightforward either.
Off by one. Linux deprecated OSS3, and OSS4 is now opensource.
And not only does it work better (in my admittedly little experience with it), it's also more in keeping with the UNIX philosophy of treating devices just like any other file. Sure, with ALSA you do have device files, but you pretty much have to use alsalib to use them AFAIK. With OSS, you get to use the standard UNIX file APIs.
I had heard that V8 was 32-bit only right now, which is why I was surprised that there was an amd64 package. But everything I've seen online (in the admittedly small amount of searching I've done) indicates that 64-bit support is a low priority. I even saw somewhere mentioned that the code makes various non-portable assumptions such as sizeof(int)==sizeof(void*), which if true means they really weren't planning for 64-bit support when they started. I hope they add proper 64-bit support soon, but I'm not holding my breath.
In the sense that it doesn't pull in the 32-bit dependencies, yes. But rather than fix it, I'll just uninstall. Chrome should hopefully support 64 bit properly at some point, and I'd rather wait until then to try it out than install a bunch of 32 bit libraries for the sole purpose of running a very alpha browser that I'll likely play around with for all of five minutes.
A friend wrote up a Gentoo ebuild for it, which I went and installed (for the amd64 version - I run an almost entirely 64 bit system). Try to run it, and got this message:
/opt/google/chrome/chrome: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
That's odd... double check... yes,/usr/lib64/libgconf-2.so.4 exists... No... they couldn't have...
Slashdot Mirror
I'm sorry, this sounds like a poor rationalization for lack of useful functionality. By this logic, you should crash the program without warning whenever invalid input is detected - it could be an attack since no program should ever provide invalid input to a function. In real life, programs have tons of bugs and diagnostic messages are hugely useful in identifying and then fixing them. Especially since the vast majority of programs are not used in a context where an attack can occur.
A 'paranoid' mode with this behavior may make sense for some people. Most people, especially those in the process of developing the software, would prefer diagnostics when things go wrong.
I disagree. There is a big difference between invalid input to a function (eg trying to convert "abc" to an integer) and a memory corruption bug. In the former case, you can return an error to the caller, and if they were written with enough attention to detail, they can fix the problem and move on, or ask the user for actually valid input, or whatever followup action may be appropriate.
In the case of a memory corruption bug, there is no way to correct the problem and move on. By the time you detect the problem, you're already hosed. You can't even rely on the fact that the program accurately knows what it was in the middle of trying to do. I think crashing is absolutely appropriate here. And if you want to debug it, then attach a debugging to the program or the resulting core dump -- all the same information you would have gotten from printed diagnostics can be found (albeit with more effort). But trying to diagnose a memory corruption bug after the fact like this is the hard way to do it anyway. You really want to catch the corruption as it happens, and the are much better tools for this (valgrind, etc).
What is involved in a port?
This list is probably not absolutely 100% complete, but it should be pretty close:
You can find links to more information on the musl wiki.
putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.
Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.
The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.
Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.
There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.
You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.
One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.
The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.
Take a look at their page on bugs found while developing musl, and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".
You do realize that CMS only published the final rule for stage 2 on August 23, right?
How have they taken the phone manufacturer out of the equation? They _are_ the phone manufacturer.
You should've wrote "raises the question"
You should have written "should've written."
Fortunately, ARM is little endian too
ARM can be configured to run as either little or big endian. Instructions are always stored in memory in little endian, but not necessarily so for data. Little endian is more common, but the ARM processor in the Wii, for example, is big endian.
"Freedom of speech" only applies to Government's interference in forms of speech. [...]
No. I keep seeing this repeated, but it's absolutely not true. Constitutionally-protected free speech only applies to the government's interference in forms of speech. [...]
Look at the post he was replying to:
I'm usually against listening to any far winged nut job, but this is freedom of expression which falls under the first amendment. [...]
Sentex wasn't explicit about it, but in context it's obvious that he was talking about constitutionally-protected free speech.
Javascript, maybe. I don't have much experience with it, so I can't comment.
But I have to disagree with HTML. HTML is not programming. Seriously, making a simple webpage in HTML is like typing a document in Word, except typing <b>text</b> instead of hitting the bold button on the toolbar. If that's programming, then typing up a paper for high school English class is too.
HTML _can_ lead into Javascript, PHP, and other facets of web programming. But it's not programming in itself, and if the goal is to introduce him to programming, making him learn HTML before he can start learning programming seems like the wrong way to go about it.
> But video games just let the market decide what will happen if it is too expensive
Part of the way the market decides on the price is that people complain when it is too expensive.
I haven't looked at the official changelog or the code yet, but I'm just as confused as you about that item. Moreso perhaps, as I have used IPv4 over firewire with two linux machines before. That was probably 5 years ago or so.
It's still missing an infrared port for transmitting phone numbers and such too, isn't it?
Merely resaving an image with a higher quality setting won't magically repopulate the high frequency coefficients, so I think this will still work in that case. Of course, if the image has gone through any sort of filtering or modification before being resaved, then all bets are off. But that's also beyond the scope of what the original poster asked for - he wanted a way to detect JPEG compression artifacts, not any extra filtering that might have also been applied.
JPEG works by breaking the image into 8x8 blocks and doing a two dimensional discrete cosine transform on each of the color planes for each block. At this point, no information is lost (except possibly by some slight inaccuracies converting from RGB to YUV as is used in JPEG). The step where the artifacts are introduced is in quantizing the coefficients. High frequency coefficients are considered less important and are quantized more than low frequency coefficients. The level of quantization is raised across the board to increase the level of compression.
Now, how is this useful? The reason heavily quantizing results in higher compression is because the coefficients get smaller. In fact, many become zero, which is particularly good for compression - and the high frequency coefficients in particular tend towards zero. So partially decode the images and look at the DCT coefficients. The image with more high frequency coefficients which are zero is likely the lower quality one.
So, that will show you which parts differ. How do you tell which is higher quality? Sure, you can probably do it by eye. But it sounds like the poster wants a fully automated method.
No it doesn't. This method has another problem (see my replies to it), but other than that, it could work. He's suggesting that to each copy of the image, you look at the difference between that copy and a blurred version of it. This will give you an idea of how sharp that copy is. And since JPEG throws out high frequency information first, resulting in blurring, it would appear at first glance that the sharper image should be the higher quality one.
As I said in another comment though, JPEG operates on blocks, and especially at very low qualities, you get sharp edges between each block. So the assumption that sharp image == high quality is not really valid.
Also, JPEG works on blocks. While it's true that JPEG gets rid of high frequency details first (and thus results in blurring), this is only useful within each block. You can have high contrast areas at the edge of each block, and this is actually often some of the most annoying artifacting in images compressed at very low quality. So just because it has sharp edges doesn't mean it's high quality.
Even faster is look at the DCT coefficients in the file itself. Doesn't even require decoding - JPEG compression works by quantizing the coefficients more heavily for higher compression rates, and particularly for the high frequency coefficients. If more high frequency coefficients are zero, it's been quantized more heavily, and is lower quality.
Now, it's not foolproof. If one copy went through some intermediate processing (color dithering or something) before the final JPEG version was saved, it may have lost quality in places not accounted for by this method. Comparing quality of two differently-sized images is also not as straightforward either.
Off by one. Linux deprecated OSS3, and OSS4 is now opensource.
And not only does it work better (in my admittedly little experience with it), it's also more in keeping with the UNIX philosophy of treating devices just like any other file. Sure, with ALSA you do have device files, but you pretty much have to use alsalib to use them AFAIK. With OSS, you get to use the standard UNIX file APIs.
I had heard that V8 was 32-bit only right now, which is why I was surprised that there was an amd64 package. But everything I've seen online (in the admittedly small amount of searching I've done) indicates that 64-bit support is a low priority. I even saw somewhere mentioned that the code makes various non-portable assumptions such as sizeof(int)==sizeof(void*), which if true means they really weren't planning for 64-bit support when they started. I hope they add proper 64-bit support soon, but I'm not holding my breath.
In the sense that it doesn't pull in the 32-bit dependencies, yes. But rather than fix it, I'll just uninstall. Chrome should hopefully support 64 bit properly at some point, and I'd rather wait until then to try it out than install a bunch of 32 bit libraries for the sole purpose of running a very alpha browser that I'll likely play around with for all of five minutes.
A friend wrote up a Gentoo ebuild for it, which I went and installed (for the amd64 version - I run an almost entirely 64 bit system). Try to run it, and got this message:
That's odd ... double check ... yes, /usr/lib64/libgconf-2.so.4 exists ... No ... they couldn't have ...
$ file /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
*facepalm*
The 64-bit Chrome is *NOT* 64-bit, and will not run on 64-bit systems which are missing a number of 32-bit libraries.