I'm not terribly sure what you mean by that. The moronic scrollbars are the only thing I know of, and that's even a separate package (which if you uninstall, or never install in the first place, you'll get the normal GTK+ scrollbar). What does Canonical do to GTK+ 3 that affects it outside of Unity?
I'm hardly a "hater" of it. Hell, I've used it since UNR, before it was even called Unity. It's great for netbooks and tablets, decent on laptops, sketchy on desktops, and absolutely horrible for multi-monitor desktops. That being said, if you're not willing to use Unity almost exactly how it's shipped, then it's useless to you because it's simply not configurable.
Even some games that use un-managed code (such as games that use the Source, Unreal Engine, or id Tech engines) don't need much work to get Linux support. The current Humble Bundle contains the first Unreal Engine 3 game (Dungeon Defenders) ported to Linux, and apparently it was done by one person! It all depends on the engine's portability. If, as you say, they use a custom engine in C# with DirectX 12, it's going to take a bit of effort to get ported. Fortunately, Steam on OS X has increased the number of games on OS X quite a bit, and because both OS X and Linux are Unix-ish (hell, OS X is UNIX on x86) and only support OpenGL, it's not super hard to port from OS X to Linux. Granted, there still is work to be done, but not as much as is needed to port from Windows to OS X or Linux without proper engine support.
I agree that initial configuration for KDE generally takes a bit more effort than some other DEs (if you want any of the fancy things), but you have to admit that KDE out of the box is far more usable than Unity is no matter what you do to it...
It's true that Mint uses Ubuntu's packages (as well as some of its own), but at least Mint escapes the Unity insanity. Canonical has shown no signs of letting up with the crazy, as seen with the Amazon search integration nonsense. That doesn't mean their packages are faulty.
Who exactly is stating the opposite? I agreed that the wording is weird, mainly because they didn't put in something like "built-in" with their statement "IE doesn't support SSL at all", but I'd hardly call it inflammatory...
There wasn't that leap to make. AC said "IE doesn't support SSL at all, it's all windows internal" which is a (possibly poorly phrased) way of saying that IE doesn't support SSL independently, it uses the SSL implementation built into Windows. Obviously IE works with SSL, it's just not actually a part of IE.
Seriously? Is it not common knowledge now that the majority of sites run on Linux with Apache (which almost certainly has all the GNU libraries and tools since it's not embedded)? I really am glad Slashdot isn't Wikipedia. How about you try spamming [citation needed] there? I'm sure that position is in demand.
Except that the person specifically mentioned 1 IP hosting several SSL-enabled domains (which is SNI), which IE cannot do on Windows XP because IE doesn't provide its own cryptographic engine. The fact remains that IE doesn't do crypto, it uses the Windows crypto library, which is more limited (including lack of SNI before Vista).
It's like saying my tablet can't do LTE because the phone that's tethered to it doesn't support LTE. It's but weirdly stated, but true. If I upgraded my phone, my tablet would get LTE, but that's hardly the point because I still don't have LTE either way.
This has nothing to do with downloading mail to your own computer. This is for people that use Gmail's ability to download mail from other mail servers. Granted, it sucks that Gmail (not Google Apps) users weren't told in advance about it, but it's not like anyone suddenly lost their ability to get their e-mail.
Security researchers have identified a botnet controlled by its creators over the Tor anonymity network.
The creators of the botnet control it over the Tor network. They aren't saying that the creators of Tor created the botnet (they didn't mention the creators of Tor at all, just the creators of the botnet), they are only saying that the people that did make the botnet use Tor for C&C. May I suggest investing in additional caffeine today?:)
What does that have to do with criminals using Tor? The federal government speaking to the creator of Tor doesn't mean that no crimes are ever committed using it.
The person you replied to with your tin foil hat spiel actually made a pretty decent point. Even if this is somehow some "bullshit plot and propaganda" (why would they wait until now to do this, by the way?), people creating tools to give themselves privacy because they don't have it otherwise because of "[s]pying on people, tracking their every movement, and abusing the legal systems of countries created a need (and a demand) for a type of security system that would protect you to the n-th degree" (quoting OP, not you) has inadvertently given criminals the same amount of privacy to do nasty things (such as hosting C&C for a botnet), and also that this would have been avoided by giving people privacy and treating them like humans. If this actually is some "bullshit plot and propaganda", there is absolutely nothing stopping it from becoming real.
Hell, I'm absolutely positive that this isn'tthefirsttime a criminal has ever used Tor to cover up crimes. So unless you actually think Silk Road was created by the government, pretty sure OP is right, and this is a problem that they brought upon themselves by removing people's privacy in the first place.
What company controls Mint? Until that happens, there's not going to be stupid things like this where the company in charge (Canonical in this case) pushes things through for no other reason than because they're in charge, and they want money. Not to mention, saying that just because Mint bases its packages on Ubuntu's means they'll follow in the same footsteps is pretty silly.
There's this thing called "common courtesy" which includes "not criticizing someone for not getting something you didn't make clear in any way at all, and half of which still doesn't make sense." Of course, nothing requires you to be courteous on Slashdot, as you astutely pointed out, but that doesn't mean it's not a good idea.
If you have to explain a whoosh that much, is it really a whoosh? One generally only says whoosh when it's pretty clear what you're trying to say.
Also, how does that make sense to say "one less thorn in the side of Windows/Firefox users" when users normally want the plug-ins (or else they wouldn't install them)? Next time, before you say whoosh, try to make your point clear so that someone that isn't you can easily figure out what you're getting at.
That's because, with the tiniest amount of common sense, one can tell the difference. Not many people (not even the zealots) would say that code has no value. For what it's worth, I've never seen it referred to as a "digital asset" outside of Wikipedia, it's always just been "asset." The fact that some people, yourself included, assumed people were referring to "asset (business)" instead of what they were really referring to, "asset (digital)" isn't changed by the fact that no one said "digital asset."
Your comment is akin to someone replying to "Linux Mint works on most computers out of the box" with "It doesn't work on my TI-89," because you missed the common sense indication that they were talking about personal computers.
The security bit is nonsense. ASLR and DEP are always opt-in, for both 32-bit and 64-bit, unless (except for DEP) the user changes it to cover all programs. There's nothing else I can find that would cover application security and be different for 32-bit and 64-bit programs.
Apparently Flash has been ported to 64-bit browsers on Windows, but that's not the only plug-in out there. Why would they maintain a piece of software that no one would use, because they can't do X on it?
And how would it be one less thorn in the side of Windows Firefox users? I use 32-bit Firefox on 64-bit Windows constantly, and have no problems whatsoever with it.
Yes, apparently they did, but it's still quite recent (and only works on Windows 7). Naturally, it took them years to come out with it after 64-bit Windows came out (yes, I'm counting XP x86_64, it was a 64-bit desktop OS). Whether or not Adobe came out with it now, they're hardly the ONLY plug-in developer. The problem of plug-ins not being ported to 64-bit browsers on Windows is hardly just Adobe's. That being said, I'm not sure why you think Flash is the only plug-in Adobe makes.
Yes, we get it, you're a person that works on everything, and so you know what you're talking about. That's nice. Some of us have been using Fx just fine (including myself), only we don't complain about it every time it comes up on Slashdot. You're not going to convince me to stop using Slashdot because you named a list of machines you work on and say that Firefox has been awful on every single one. If Fx stops working well on my machines, then I'll switch, but I'm not going to switch just because someone says Fx doesn't work for them.
If you're talking about HTML5 video then fine, but if you're talking about Flash, why in the hell are you blaming the browser for that? Naturally, on the three computers I regularly use, I have exactly zero of the problems you mention, with both HTML5 and Flash videos. Anecdotes are completely pointless, because everyone can have different experiences. Yours aren't special because you can list a lot of computers.
That was about the 64-bit build, running exclusively in 64-bit mode. Running the 32-bit version of Firefox on 64-bit Windows is still fully supported. The big problem with 64-bit Firefox on Windows was that, unlike Linux, plug-in developers (read: Adobe) didn't port their plug-ins to 64-bit, and only released them in 32-bit variants.
Yes, it depends on how it was allocated. glibc uses sbrk for small allocations (as you said, under 128 KB) and mmap for larger ones. It's actually interesting to read the mallopt man page. It seems to be glibc-only, but it lets you tune all the settings we're talking about, and then some. In any case, small allocations are the big problem, because they're put in the data segment and the data segment can't be shrunk past any data still allocated, so fragmentation means glibc can't use sbrk to shrink it again (at least past the point it's fragmented at). If all a program does is small allocations, and it fragments a lot, then the memory usage of the program wouldn't really go down. Of course, it's worth noting that M_TRIM_THRESHOLD is, by default, 128 KB, so freed memory won't always be returned immediately. You can also change M_MMAP_THRESHOLD to control what size allocation will be done on the data segment and with mmap.
For large amounts, yes, glibc will mmap them and munmap them when freed. I had forgotten, though, that Firefox switched to jemalloc. It seems like jemalloc never uses sbrk, and it considers "large" allocations (large enough to allocate a dedicated block) 4 KB instead of 128 KB. It also uses multiple arenas, which seems like it would complicate things even more. I don't know if using jemalloc helps guard against memory fragmentation or not, but its allocation strategy seems sane. At the very least, some pages should be able to be returned, even if they're one of the older pages, which should help a bit. With sbrk in glibc and Windows using the heap, only the most recently allocated memory (and the freed memory before it, until it hits a still-in-use point) can be freed, but that doesn't seem to apply to jemalloc, as long as the freed memory makes up a whole page.
Of course, with Windows, they don't reveal everything about it as it's proprietary, but it does seem like memory is always allocated on the heap, and the memory will always get returned (perhaps except in cases of extreme fragmentation) eventually, but by no means immediately (in case the program wants to use it again). A program can choose to use a Windows-specific function to return it right away (_heapmin). _heapmin won't return things that are below blocks on the heap that are still allocated, though, so fragmentation is still a big issue.
I can understand why a process might want to free memory but keep it around for later allocations (and Firefox may very well tweak jemalloc to do it) but with virtual memory, there's no guarantee the first allocation was contiguous anyway. I think it would be better for the process to return memory so other things can use it, and maybe keep a small amount handy, but not everything that's been freed so far.
Also, I apologize if my post came off as rude. I re-read it later and it seemed rude to me, which was absolutely not my intention. As a programmer, I don't strictly need to know how the memory allocator works (as long as it works), but I find it extremely interesting, and knowing how things happen makes it easier to prevent memory fragmentation, so I think people should know, even if for no other reason than it's quite interesting.
Just to clarify, you do generally need to free a whole page of memory for it to be returned, so technically not every free would return the memory to the OS, but depending on the page size, allocations of a certain size almost always should. I don't know if you're specifically talking about Firefox, and if it uses lots of small allocations (haven't really dug around the source, so I'm not sure) that are unlikely to be freed in way that causes pages to be returned, then I apologize.
Slashdot Mirror
I'm not terribly sure what you mean by that. The moronic scrollbars are the only thing I know of, and that's even a separate package (which if you uninstall, or never install in the first place, you'll get the normal GTK+ scrollbar). What does Canonical do to GTK+ 3 that affects it outside of Unity?
I'm hardly a "hater" of it. Hell, I've used it since UNR, before it was even called Unity. It's great for netbooks and tablets, decent on laptops, sketchy on desktops, and absolutely horrible for multi-monitor desktops. That being said, if you're not willing to use Unity almost exactly how it's shipped, then it's useless to you because it's simply not configurable.
Even some games that use un-managed code (such as games that use the Source, Unreal Engine, or id Tech engines) don't need much work to get Linux support. The current Humble Bundle contains the first Unreal Engine 3 game (Dungeon Defenders) ported to Linux, and apparently it was done by one person! It all depends on the engine's portability. If, as you say, they use a custom engine in C# with DirectX 12, it's going to take a bit of effort to get ported. Fortunately, Steam on OS X has increased the number of games on OS X quite a bit, and because both OS X and Linux are Unix-ish (hell, OS X is UNIX on x86) and only support OpenGL, it's not super hard to port from OS X to Linux. Granted, there still is work to be done, but not as much as is needed to port from Windows to OS X or Linux without proper engine support.
I agree that initial configuration for KDE generally takes a bit more effort than some other DEs (if you want any of the fancy things), but you have to admit that KDE out of the box is far more usable than Unity is no matter what you do to it...
It's true that Mint uses Ubuntu's packages (as well as some of its own), but at least Mint escapes the Unity insanity. Canonical has shown no signs of letting up with the crazy, as seen with the Amazon search integration nonsense. That doesn't mean their packages are faulty.
Not sure about Unity, but even GNOME 3 has nowhere near that overhead in my experience. Sure, you take a hit, but 50% is insane.
Who exactly is stating the opposite? I agreed that the wording is weird, mainly because they didn't put in something like "built-in" with their statement "IE doesn't support SSL at all", but I'd hardly call it inflammatory...
There wasn't that leap to make. AC said "IE doesn't support SSL at all, it's all windows internal" which is a (possibly poorly phrased) way of saying that IE doesn't support SSL independently, it uses the SSL implementation built into Windows. Obviously IE works with SSL, it's just not actually a part of IE.
Seriously? Is it not common knowledge now that the majority of sites run on Linux with Apache (which almost certainly has all the GNU libraries and tools since it's not embedded)? I really am glad Slashdot isn't Wikipedia. How about you try spamming [citation needed] there? I'm sure that position is in demand.
Except that the person specifically mentioned 1 IP hosting several SSL-enabled domains (which is SNI), which IE cannot do on Windows XP because IE doesn't provide its own cryptographic engine. The fact remains that IE doesn't do crypto, it uses the Windows crypto library, which is more limited (including lack of SNI before Vista).
It's like saying my tablet can't do LTE because the phone that's tethered to it doesn't support LTE. It's but weirdly stated, but true. If I upgraded my phone, my tablet would get LTE, but that's hardly the point because I still don't have LTE either way.
This has nothing to do with downloading mail to your own computer. This is for people that use Gmail's ability to download mail from other mail servers. Granted, it sucks that Gmail (not Google Apps) users weren't told in advance about it, but it's not like anyone suddenly lost their ability to get their e-mail.
Security researchers have identified a botnet controlled by its creators over the Tor anonymity network.
The creators of the botnet control it over the Tor network. They aren't saying that the creators of Tor created the botnet (they didn't mention the creators of Tor at all, just the creators of the botnet), they are only saying that the people that did make the botnet use Tor for C&C. May I suggest investing in additional caffeine today? :)
What does that have to do with criminals using Tor? The federal government speaking to the creator of Tor doesn't mean that no crimes are ever committed using it.
The person you replied to with your tin foil hat spiel actually made a pretty decent point. Even if this is somehow some "bullshit plot and propaganda" (why would they wait until now to do this, by the way?), people creating tools to give themselves privacy because they don't have it otherwise because of "[s]pying on people, tracking their every movement, and abusing the legal systems of countries created a need (and a demand) for a type of security system that would protect you to the n-th degree" (quoting OP, not you) has inadvertently given criminals the same amount of privacy to do nasty things (such as hosting C&C for a botnet), and also that this would have been avoided by giving people privacy and treating them like humans. If this actually is some "bullshit plot and propaganda", there is absolutely nothing stopping it from becoming real.
Hell, I'm absolutely positive that this isn't the first time a criminal has ever used Tor to cover up crimes. So unless you actually think Silk Road was created by the government, pretty sure OP is right, and this is a problem that they brought upon themselves by removing people's privacy in the first place.
What company controls Mint? Until that happens, there's not going to be stupid things like this where the company in charge (Canonical in this case) pushes things through for no other reason than because they're in charge, and they want money. Not to mention, saying that just because Mint bases its packages on Ubuntu's means they'll follow in the same footsteps is pretty silly.
There's this thing called "common courtesy" which includes "not criticizing someone for not getting something you didn't make clear in any way at all, and half of which still doesn't make sense." Of course, nothing requires you to be courteous on Slashdot, as you astutely pointed out, but that doesn't mean it's not a good idea.
If you have to explain a whoosh that much, is it really a whoosh? One generally only says whoosh when it's pretty clear what you're trying to say.
Also, how does that make sense to say "one less thorn in the side of Windows/Firefox users" when users normally want the plug-ins (or else they wouldn't install them)? Next time, before you say whoosh, try to make your point clear so that someone that isn't you can easily figure out what you're getting at.
That's because, with the tiniest amount of common sense, one can tell the difference. Not many people (not even the zealots) would say that code has no value. For what it's worth, I've never seen it referred to as a "digital asset" outside of Wikipedia, it's always just been "asset." The fact that some people, yourself included, assumed people were referring to "asset (business)" instead of what they were really referring to, "asset (digital)" isn't changed by the fact that no one said "digital asset."
Your comment is akin to someone replying to "Linux Mint works on most computers out of the box" with "It doesn't work on my TI-89," because you missed the common sense indication that they were talking about personal computers.
Because that's not the definition of asset everyone else uses. Yes, source code is an asset to the company, but it's not a "digital asset."
You're abusing the word asset to mean something it doesn't. See https://en.wikipedia.org/wiki/Digital_asset. Notice how code isn't there.
The security bit is nonsense. ASLR and DEP are always opt-in, for both 32-bit and 64-bit, unless (except for DEP) the user changes it to cover all programs. There's nothing else I can find that would cover application security and be different for 32-bit and 64-bit programs.
Apparently Flash has been ported to 64-bit browsers on Windows, but that's not the only plug-in out there. Why would they maintain a piece of software that no one would use, because they can't do X on it?
And how would it be one less thorn in the side of Windows Firefox users? I use 32-bit Firefox on 64-bit Windows constantly, and have no problems whatsoever with it.
Yes, apparently they did, but it's still quite recent (and only works on Windows 7). Naturally, it took them years to come out with it after 64-bit Windows came out (yes, I'm counting XP x86_64, it was a 64-bit desktop OS). Whether or not Adobe came out with it now, they're hardly the ONLY plug-in developer. The problem of plug-ins not being ported to 64-bit browsers on Windows is hardly just Adobe's. That being said, I'm not sure why you think Flash is the only plug-in Adobe makes.
Yes, we get it, you're a person that works on everything, and so you know what you're talking about. That's nice. Some of us have been using Fx just fine (including myself), only we don't complain about it every time it comes up on Slashdot. You're not going to convince me to stop using Slashdot because you named a list of machines you work on and say that Firefox has been awful on every single one. If Fx stops working well on my machines, then I'll switch, but I'm not going to switch just because someone says Fx doesn't work for them.
If you're talking about HTML5 video then fine, but if you're talking about Flash, why in the hell are you blaming the browser for that? Naturally, on the three computers I regularly use, I have exactly zero of the problems you mention, with both HTML5 and Flash videos. Anecdotes are completely pointless, because everyone can have different experiences. Yours aren't special because you can list a lot of computers.
That was about the 64-bit build, running exclusively in 64-bit mode. Running the 32-bit version of Firefox on 64-bit Windows is still fully supported. The big problem with 64-bit Firefox on Windows was that, unlike Linux, plug-in developers (read: Adobe) didn't port their plug-ins to 64-bit, and only released them in 32-bit variants.
Yes, it depends on how it was allocated. glibc uses sbrk for small allocations (as you said, under 128 KB) and mmap for larger ones. It's actually interesting to read the mallopt man page. It seems to be glibc-only, but it lets you tune all the settings we're talking about, and then some. In any case, small allocations are the big problem, because they're put in the data segment and the data segment can't be shrunk past any data still allocated, so fragmentation means glibc can't use sbrk to shrink it again (at least past the point it's fragmented at). If all a program does is small allocations, and it fragments a lot, then the memory usage of the program wouldn't really go down. Of course, it's worth noting that M_TRIM_THRESHOLD is, by default, 128 KB, so freed memory won't always be returned immediately. You can also change M_MMAP_THRESHOLD to control what size allocation will be done on the data segment and with mmap.
For large amounts, yes, glibc will mmap them and munmap them when freed. I had forgotten, though, that Firefox switched to jemalloc. It seems like jemalloc never uses sbrk, and it considers "large" allocations (large enough to allocate a dedicated block) 4 KB instead of 128 KB. It also uses multiple arenas, which seems like it would complicate things even more. I don't know if using jemalloc helps guard against memory fragmentation or not, but its allocation strategy seems sane. At the very least, some pages should be able to be returned, even if they're one of the older pages, which should help a bit. With sbrk in glibc and Windows using the heap, only the most recently allocated memory (and the freed memory before it, until it hits a still-in-use point) can be freed, but that doesn't seem to apply to jemalloc, as long as the freed memory makes up a whole page.
Of course, with Windows, they don't reveal everything about it as it's proprietary, but it does seem like memory is always allocated on the heap, and the memory will always get returned (perhaps except in cases of extreme fragmentation) eventually, but by no means immediately (in case the program wants to use it again). A program can choose to use a Windows-specific function to return it right away (_heapmin). _heapmin won't return things that are below blocks on the heap that are still allocated, though, so fragmentation is still a big issue.
I can understand why a process might want to free memory but keep it around for later allocations (and Firefox may very well tweak jemalloc to do it) but with virtual memory, there's no guarantee the first allocation was contiguous anyway. I think it would be better for the process to return memory so other things can use it, and maybe keep a small amount handy, but not everything that's been freed so far.
Also, I apologize if my post came off as rude. I re-read it later and it seemed rude to me, which was absolutely not my intention. As a programmer, I don't strictly need to know how the memory allocator works (as long as it works), but I find it extremely interesting, and knowing how things happen makes it easier to prevent memory fragmentation, so I think people should know, even if for no other reason than it's quite interesting.
Just to clarify, you do generally need to free a whole page of memory for it to be returned, so technically not every free would return the memory to the OS, but depending on the page size, allocations of a certain size almost always should. I don't know if you're specifically talking about Firefox, and if it uses lots of small allocations (haven't really dug around the source, so I'm not sure) that are unlikely to be freed in way that causes pages to be returned, then I apologize.