I tried very hard to like Seamonkey. I even wrote an extractor for the intentionally corrupted omni.ja (ZIP file with a bad central index) so that I could patch the XUL files for the UI to get it looking nice.
I ran into several problems: the allow-popups/cookie manager was the most obtuse UI I've ever seen in all my years of using computers, video wasn't capable of going full-screen, the loss of the element inspector was a major blow both to web development and using Adblock Plus with my own CSS blocking rules, etc.
But this probably will be where I ultimately fall back to once I can no longer run older Firefox copies anymore (probably due to sites relying on some new feature not in FF28.)
I'm not really all that trusting of it just yet. Seems like a really tiny dev team, and I am not confident they'll be able to keep up as the Mozilla codebase drifts further and further apart from theirs. But I hope I'm wrong.
No they're not. Now that DRM codecs are widely available in every major browser, there's no cost associated with lost customers who don't have the DRM extensions in their browsers. The end result of Mozilla et al caving on DRM is that more sites are going to start using it than would have otherwise.
If I want to pay to watch DRMed Netflix content, then I have a $30 TV stick for that. I didn't need DRM on the web for that.
Google just removed 200 extensions that turned out to be malicious and would steal login credentials, inject ads and other such fun things.
I don't want to have to install a dozen third-party extensions from people I don't know or trust with handles like XxFoX69eRxX to get functionality back which I already had.
Which about:config value can I tweak to turn off Australis and have normal navigation+refresh+home buttons, and tabs under the URL bar? Which one will let me turn off download history (without killing my browser history as well)? Which one will let me show the compact one-line URL bar dropdown results? Which one will let me install unsigned extensions again? Which one will let me use HTTP/2 without TLS, as the RFC defines?
I don't know the answer, but it would be quite easy for Firefox+DRM to only be available in the released binaries, and the source code you download to only be the Firefox-DRM portion. Much like Chromium versus Chrome.
Because I investigate the designs chosen, and find myself agreeing with them. For just one example, take the design of/dev/random => http://en.wikipedia.org/?title...
I've been looking, but so far I haven't found a Linux vs FreeBSD difference where I thought, "wow, Linux does this a whole lot better." I'm sure they exist, and that I'll come across them eventually.
If there comes a time when I feel the FreeBSD devs start doing a bunch of crazy things as well, then I'll start investigating Minix, Hurd, Haiku, etc.
I'm not really even that bothered by the Linux kernel choices, but damned if I'm using Poettering's garbage again after suffering through PulseAudio.
What are you talking about? The FreeBSD forums have a ton of news members lately, all moving away from systemd. Including myself.
And rc.d is absolutely nothing like systemd. It's far more like SysVinit in that it's just an init system, and not a (DNS server, binary logging system, network time daemon, login daemon, console daemon, HTTP server, QR-code generator, hardware device manager, etc etc etc etc etc etc etc etc etc etc.) Only rc.d is far simpler and nicer than SysVinit. It's a thing of beauty. I set up an HTTP daemon by making a text file with five lines of text in it. See for yourself.
And how about this new-age bullshit trend on sites like medium.com that think you want to look at a literal, full-screen image of some unrelated stock art picture before you get to a single word of the actual story; followed by repeated 1920x1080 stock art for every three paragraphs of text?
View -> Page Style -> No Style is a godsend on some of these sites.
If by old-school Firefox you mean, "eight years prior to its existence Netscape Navigator", then yes.
I really wanted to switch to Seamonkey; but: it can't do fullscreen video playback, it has no "inspect element" functionality, and its cookie/popup manager is the worst thing I've ever seen in my life. It's also not fun writing a custom extraction tool to get the resource files out of their intentionally-corrupted omni.ja(r) file to drag the interface kicking and screaming out of 1995. Learning magic trick with userChrome.css only gets you so far with Seamonkey, but can't make the tab bar even remotely sensible.
Then disable HTTP-only on *.cn instead. Leave other countries that don't pull this shit alone. Hell, that might actually be a nice punitive action against China for that; given our governments don't have the balls to do anything about it for obvious trade/debt reasons.
I was fairly annoyed after reading the (as usual) poor Slashdot title. But even the link summary here mentions that taking these classes will be optional. So long as that remains the case, then (ignoring any budget constraints) this is a good thing.
I don't know why you want to modify strings in-place
Because I care about performance? Memory allocations are extremely heavyweight. Doing that in a tight loop (say, an assembler building a large project) can really bog down your performance. It's nice to offer both, but you'd need some kind of naming convention since they can't both be called replace. So when I don't want in-place, I just say auto copy = string{mystring}.replace("from", "to"); and move semantics avoids the extra copy.
std::string doesn't offer either version of replace (in-place or new copy), it just has a version that is basically memcpy with bounds-checking. That assumes you already know where the string is, and that from/to are of equal length.
Making it a template just because a bunch of loonines thought that you could not do Unicode unless you made all the characters the same size was another mistake. Not only is the code unreadable and impossible to optimize, those idiots ended up with UTF-16 which is variable sized anyway. Duh.
Oh, don't get me started on UCS-2/UTF-16, wchar_t and A/W (Windows) nonsense. I've built wrapper functions for basically every Windows function so that I can use UTF-8 like sane people. I can't believe all that BS still exists, even after surrogate pairs came about.
This exactly. When I tried to use the STL and Boost, I hated the language as well. The STL is so crippled that std::string is basically std::vector. If you want to replace "foo" with "bar" in a string, you have to write your own function to do it, because std::string::replace is just a glorified memcpy wrapper. Same goes for char transform, string reverse, split/explode, etc.
And since C++ lacks unified function call syntax, you can't extend std::string unless you subclass it (and then everyone does that, and they're not compatible with each other.) So instead, people revert back to treating C++ like C with shit like "replace(mystring, "from", "to")" instead of "mystring.replace("from", "to")". Yet it goes out of its way to offer esoteric features like custom allocators.
Qt is a rather buggy toolkit, because it tries to do way too much for its own good. (seriously, you can apply a CSS stylesheet to do a radial gradient effect on the text color of a QLabel. Yes, that's cool, but there's so much code that it's 40MB of run-time DLLs, takes hours to compile said library DLLs, and is just full of bugs that vary per platform.) However, once you get past moc/signals/slots (function pointers, and now lambdas, work for 99% of the cases you'd encounter), the API is truly a thing of beauty. (you might even like signals/slots, but I personally can't stand all the added build rules, or the "just use qmake" crowd.)
Since I've started just writing my own C++ libraries, I've found the language to be a thing of beauty. The obvious downside is that the system won't work if everyone uses their own libraries (Qt does this as well, eg QString, QList, etc.) C++14 really needs a renaissance, where a new team builds a new run-time library from scratch, with clean designs as with Qt.
Easy. Start posting the links on major portals that even the UK govt wouldn't dare block. Link them behind HTTPS (so partial URI blocking isn't possible) of Twitter, Facebook, etc.
You could probably link to said Twitter feed or whatever from your actual site, unless they start banning links to links to proxies to sites. But once people find out about the major portal accounts, they'll just start going there instead for updated proxies.
climate change => weather modification, temperature shifting
global warming => worldwide heating, earth roasting
sustainability => maintainability, continuity
Florida => laughingstock of the world
You're welcome to tell yourself whatever narrative you want to ignore the criticism. I really don't care, even if you are right (and I still think you aren't.) I abandoned Linux for the BSDs over this, as I suspect many others have, and I'm not looking back. I found a system that was far cleaner, far leaner, less dogmatic about licensing (eg I don't have to run broken-as-hell cdrkit, I can use the proper, working cdrtools; firefox isn't renamed to something stupid like iceweasel; etc), with a better file system, network packet filter, with better all-around design (of eg/dev/random, no/proc, etc) and superior leadership (luminaries such as PHK.) Of course, the more people that follow suit, the more unanimous you'll think systemd support is. But oh well.
With the MTRR tweak, I can even watch video at 2560x1600 at 60fps. I've benchmarked it and I can get up to 95fps of solid memory copying into VRAM. Compositing works fine, but I turn off all but shadows. It also helps to run at 16bpp (half the bandwidth needed per screen fill), which only really hurts you when you're working with artificial gradients, or are a photo editor. Kind of sucky to give up the color detail, but I'll take twice the speed over colors the majority of which I cannot distinguish. The one thing I lament heavily is that there's no Vsync support. It's impossible to even add it manually: the video card doesn't provide Vsync timing info at all (even tried probing the VGA ports and looking at the VESA timing extensions... they don't work on this card.)
I've also been thinking about running a headless server for stability reasons, but haven't gone that far yet. If Xorg+Xfce eventually falls apart entirely over systemd; then I'll probably resort to running my own basic apps (text editor, file manager, terminal emulator, MP3 player) using FreeBSD's ioctl's for setting VESA mode right from the console. Then I'll just use my Windows box next to it for web browsing, movie watching and gaming.
Unfortunately, I doubt we'll see a lot more pushback on this. Linux users are quick to complain when Windows/OS X software doesn't run on Linux, yet are surprisingly hypocritical to not care when Linux software doesn't run on other systems (BSDs, Haiku, etc.) The BSD ports trees are littered with patches for pointless Linuxisms. They won't even add trivial compatibility features like SO_NOSIGPIPE to their system. Of course in the case of systemd, I really couldn't be happier that Poettering has a raging hate-on for it. I don't want his shit running on BSD either.
I switched to VESA. I'm not shitting you, either. I found a card that handles my native widescreen resolution, and I'm going to keep that card as long as humanly possible. I might even go buy a few more of them for backups. VESA is slow out of the box, but when you use tools to set the MTRR to write-combine (FreeBSD ships such a tool called memcontrol), then it speeds up by more than an order of magnitude (no exaggeration.)
So long as you're not playing hi-res 3D games (I'm not), problem solved. I don't have to deal with nVidia binary blob kernel panics, I don't have to deal with AMD rendering bugs, I don't have to deal with Intel GPUs only coming on certain motherboards and lacking PCIe cards, etc.
I suspect that what's going to happen with systemd requirements will be a combination of systemd emulation (OpenBSD already working on it), patching out code, and eventually just freezing ports at older versions. The most major software programs aren't going to become dependent on this crap, because they already need to run on Windows, OS X, etc. Even in the worst case scenario, we're going to be fine for at least another decade.
In the very, very long-term... the solution could well end up being that FreeBSD and Linux diverge to their own display servers and software stacks. I've been starting on some work to that effect, myself, but am going about it top-down (starting at the UI toolkit) rather than bottom-up (from the display server.)
It's good not to think of it as "a small number of detractors, and a lot of supporters." The real breakdown is, "a small number of proponents, a small number of detractors, and a huge swath of people who don't know or care enough to have an opinion on the matter." The real question is, "what's the breakdown of people who actually know and care enough?" In that regard, it's a lot closer to 50/50, and honestly, I'd suggest the anti-systemd crowd is in the majority here. People who don't care about an issue shouldn't be counted as "on your side", because they'd just as easily be "on their side" if you weren't the default choice.
Slashdot Mirror
I tried very hard to like Seamonkey. I even wrote an extractor for the intentionally corrupted omni.ja (ZIP file with a bad central index) so that I could patch the XUL files for the UI to get it looking nice.
I ran into several problems: the allow-popups/cookie manager was the most obtuse UI I've ever seen in all my years of using computers, video wasn't capable of going full-screen, the loss of the element inspector was a major blow both to web development and using Adblock Plus with my own CSS blocking rules, etc.
But this probably will be where I ultimately fall back to once I can no longer run older Firefox copies anymore (probably due to sites relying on some new feature not in FF28.)
I'm not really all that trusting of it just yet. Seems like a really tiny dev team, and I am not confident they'll be able to keep up as the Mozilla codebase drifts further and further apart from theirs. But I hope I'm wrong.
Also, there's no FreeBSD port available yet.
No they're not. Now that DRM codecs are widely available in every major browser, there's no cost associated with lost customers who don't have the DRM extensions in their browsers. The end result of Mozilla et al caving on DRM is that more sites are going to start using it than would have otherwise.
If I want to pay to watch DRMed Netflix content, then I have a $30 TV stick for that. I didn't need DRM on the web for that.
Google just removed 200 extensions that turned out to be malicious and would steal login credentials, inject ads and other such fun things.
I don't want to have to install a dozen third-party extensions from people I don't know or trust with handles like XxFoX69eRxX to get functionality back which I already had.
Which about:config value can I tweak to turn off Australis and have normal navigation+refresh+home buttons, and tabs under the URL bar? Which one will let me turn off download history (without killing my browser history as well)? Which one will let me show the compact one-line URL bar dropdown results? Which one will let me install unsigned extensions again? Which one will let me use HTTP/2 without TLS, as the RFC defines?
You and me both. I'm stuck on FF28, which is the last version with a sane UI.
Due to security concerns, I'm probably going to have to start doing all my web browsing inside of a VM soon.
Really wish Opera were open source. Vivaldi looks like even more of a trainwreck UI-wise.
I don't know the answer, but it would be quite easy for Firefox+DRM to only be available in the released binaries, and the source code you download to only be the Firefox-DRM portion. Much like Chromium versus Chrome.
Because I investigate the designs chosen, and find myself agreeing with them. For just one example, take the design of /dev/random => http://en.wikipedia.org/?title...
I've been looking, but so far I haven't found a Linux vs FreeBSD difference where I thought, "wow, Linux does this a whole lot better." I'm sure they exist, and that I'll come across them eventually.
If there comes a time when I feel the FreeBSD devs start doing a bunch of crazy things as well, then I'll start investigating Minix, Hurd, Haiku, etc.
I'm not really even that bothered by the Linux kernel choices, but damned if I'm using Poettering's garbage again after suffering through PulseAudio.
Which is probably why FreeBSD is an OS and Linux is a kernel.
The difference is that I trust and support the decisions of the FreeBSD leadership. I cannot say the same for Lennart Poettering.
What are you talking about? The FreeBSD forums have a ton of news members lately, all moving away from systemd. Including myself.
And rc.d is absolutely nothing like systemd. It's far more like SysVinit in that it's just an init system, and not a (DNS server, binary logging system, network time daemon, login daemon, console daemon, HTTP server, QR-code generator, hardware device manager, etc etc etc etc etc etc etc etc etc etc.) Only rc.d is far simpler and nicer than SysVinit. It's a thing of beauty. I set up an HTTP daemon by making a text file with five lines of text in it. See for yourself.
Use Adblock Plus to hide those.
I do the same for, "your version of Firefox is too old to view this site", even though it's like six months old >.>
And how about this new-age bullshit trend on sites like medium.com that think you want to look at a literal, full-screen image of some unrelated stock art picture before you get to a single word of the actual story; followed by repeated 1920x1080 stock art for every three paragraphs of text?
View -> Page Style -> No Style is a godsend on some of these sites.
If by old-school Firefox you mean, "eight years prior to its existence Netscape Navigator", then yes.
I really wanted to switch to Seamonkey; but: it can't do fullscreen video playback, it has no "inspect element" functionality, and its cookie/popup manager is the worst thing I've ever seen in my life. It's also not fun writing a custom extraction tool to get the resource files out of their intentionally-corrupted omni.ja(r) file to drag the interface kicking and screaming out of 1995. Learning magic trick with userChrome.css only gets you so far with Seamonkey, but can't make the tab bar even remotely sensible.
Thankfully, Poettering is staunchly anti-portability, so systemd can't run on *BSD or Hurd. I consider that the only positive feature of systemd.
Then disable HTTP-only on *.cn instead. Leave other countries that don't pull this shit alone. Hell, that might actually be a nice punitive action against China for that; given our governments don't have the balls to do anything about it for obvious trade/debt reasons.
Yeah, that had to be the most obvious false flag post I've seen in years. It's like they're not even trying.
I was fairly annoyed after reading the (as usual) poor Slashdot title. But even the link summary here mentions that taking these classes will be optional. So long as that remains the case, then (ignoring any budget constraints) this is a good thing.
Because I care about performance? Memory allocations are extremely heavyweight. Doing that in a tight loop (say, an assembler building a large project) can really bog down your performance. It's nice to offer both, but you'd need some kind of naming convention since they can't both be called replace. So when I don't want in-place, I just say auto copy = string{mystring}.replace("from", "to"); and move semantics avoids the extra copy.
std::string doesn't offer either version of replace (in-place or new copy), it just has a version that is basically memcpy with bounds-checking. That assumes you already know where the string is, and that from/to are of equal length.
Oh, don't get me started on UCS-2/UTF-16, wchar_t and A/W (Windows) nonsense. I've built wrapper functions for basically every Windows function so that I can use UTF-8 like sane people. I can't believe all that BS still exists, even after surrogate pairs came about.
This exactly. When I tried to use the STL and Boost, I hated the language as well. The STL is so crippled that std::string is basically std::vector. If you want to replace "foo" with "bar" in a string, you have to write your own function to do it, because std::string::replace is just a glorified memcpy wrapper. Same goes for char transform, string reverse, split/explode, etc.
And since C++ lacks unified function call syntax, you can't extend std::string unless you subclass it (and then everyone does that, and they're not compatible with each other.) So instead, people revert back to treating C++ like C with shit like "replace(mystring, "from", "to")" instead of "mystring.replace("from", "to")". Yet it goes out of its way to offer esoteric features like custom allocators.
Qt is a rather buggy toolkit, because it tries to do way too much for its own good. (seriously, you can apply a CSS stylesheet to do a radial gradient effect on the text color of a QLabel. Yes, that's cool, but there's so much code that it's 40MB of run-time DLLs, takes hours to compile said library DLLs, and is just full of bugs that vary per platform.) However, once you get past moc/signals/slots (function pointers, and now lambdas, work for 99% of the cases you'd encounter), the API is truly a thing of beauty. (you might even like signals/slots, but I personally can't stand all the added build rules, or the "just use qmake" crowd.)
Since I've started just writing my own C++ libraries, I've found the language to be a thing of beauty. The obvious downside is that the system won't work if everyone uses their own libraries (Qt does this as well, eg QString, QList, etc.) C++14 really needs a renaissance, where a new team builds a new run-time library from scratch, with clean designs as with Qt.
Easy. Start posting the links on major portals that even the UK govt wouldn't dare block. Link them behind HTTPS (so partial URI blocking isn't possible) of Twitter, Facebook, etc.
You could probably link to said Twitter feed or whatever from your actual site, unless they start banning links to links to proxies to sites. But once people find out about the major portal accounts, they'll just start going there instead for updated proxies.
climate change => weather modification, temperature shifting
global warming => worldwide heating, earth roasting
sustainability => maintainability, continuity
Florida => laughingstock of the world
Easy, right?
You're welcome to tell yourself whatever narrative you want to ignore the criticism. I really don't care, even if you are right (and I still think you aren't.) I abandoned Linux for the BSDs over this, as I suspect many others have, and I'm not looking back. I found a system that was far cleaner, far leaner, less dogmatic about licensing (eg I don't have to run broken-as-hell cdrkit, I can use the proper, working cdrtools; firefox isn't renamed to something stupid like iceweasel; etc), with a better file system, network packet filter, with better all-around design (of eg /dev/random, no /proc, etc) and superior leadership (luminaries such as PHK.) Of course, the more people that follow suit, the more unanimous you'll think systemd support is. But oh well.
With the MTRR tweak, I can even watch video at 2560x1600 at 60fps. I've benchmarked it and I can get up to 95fps of solid memory copying into VRAM. Compositing works fine, but I turn off all but shadows. It also helps to run at 16bpp (half the bandwidth needed per screen fill), which only really hurts you when you're working with artificial gradients, or are a photo editor. Kind of sucky to give up the color detail, but I'll take twice the speed over colors the majority of which I cannot distinguish. The one thing I lament heavily is that there's no Vsync support. It's impossible to even add it manually: the video card doesn't provide Vsync timing info at all (even tried probing the VGA ports and looking at the VESA timing extensions ... they don't work on this card.)
I've also been thinking about running a headless server for stability reasons, but haven't gone that far yet. If Xorg+Xfce eventually falls apart entirely over systemd; then I'll probably resort to running my own basic apps (text editor, file manager, terminal emulator, MP3 player) using FreeBSD's ioctl's for setting VESA mode right from the console. Then I'll just use my Windows box next to it for web browsing, movie watching and gaming.
Unfortunately, I doubt we'll see a lot more pushback on this. Linux users are quick to complain when Windows/OS X software doesn't run on Linux, yet are surprisingly hypocritical to not care when Linux software doesn't run on other systems (BSDs, Haiku, etc.) The BSD ports trees are littered with patches for pointless Linuxisms. They won't even add trivial compatibility features like SO_NOSIGPIPE to their system. Of course in the case of systemd, I really couldn't be happier that Poettering has a raging hate-on for it. I don't want his shit running on BSD either.
I switched to VESA. I'm not shitting you, either. I found a card that handles my native widescreen resolution, and I'm going to keep that card as long as humanly possible. I might even go buy a few more of them for backups. VESA is slow out of the box, but when you use tools to set the MTRR to write-combine (FreeBSD ships such a tool called memcontrol), then it speeds up by more than an order of magnitude (no exaggeration.)
... the solution could well end up being that FreeBSD and Linux diverge to their own display servers and software stacks. I've been starting on some work to that effect, myself, but am going about it top-down (starting at the UI toolkit) rather than bottom-up (from the display server.)
So long as you're not playing hi-res 3D games (I'm not), problem solved. I don't have to deal with nVidia binary blob kernel panics, I don't have to deal with AMD rendering bugs, I don't have to deal with Intel GPUs only coming on certain motherboards and lacking PCIe cards, etc.
I suspect that what's going to happen with systemd requirements will be a combination of systemd emulation (OpenBSD already working on it), patching out code, and eventually just freezing ports at older versions. The most major software programs aren't going to become dependent on this crap, because they already need to run on Windows, OS X, etc. Even in the worst case scenario, we're going to be fine for at least another decade.
In the very, very long-term
It's good not to think of it as "a small number of detractors, and a lot of supporters." The real breakdown is, "a small number of proponents, a small number of detractors, and a huge swath of people who don't know or care enough to have an opinion on the matter." The real question is, "what's the breakdown of people who actually know and care enough?" In that regard, it's a lot closer to 50/50, and honestly, I'd suggest the anti-systemd crowd is in the majority here. People who don't care about an issue shouldn't be counted as "on your side", because they'd just as easily be "on their side" if you weren't the default choice.