I haven't needed to bypass my Linux distro and install a vanilla kernel in over ten years. I can wait. If it hasn't been packaged by the major distributions yet, it also hasn't been widely deployed. There are some highly competent kernel package maintainers out there, and they're likely to catch a lot of things themselves.
Then there's the package release and its early adopters (Debian, for example, releases the latest kernels in Experimental and/or Unstable, letting them cook for a while). I typically pick up new kernels when they're in Debian Testing or Unstable (if I really want a new feature). This minimizes the chance of running into problems.
(note, this works best for people using standard hardware. ymmv regarding embedded or obscure devices)
BitTorrent Sync is not open-source software, nor do they appear to have plans to make it that. Maybe in time we'll have a F/OSS client for the protocol (though I don't know if they've even opened the protocol yet, so that might be an extra hurdle).
However, it may not be necessary; set up an SSH server (which gives you SFTP) for uploads, perhaps even use one of the myriads of HTTP file upload mechanisms and guard it with some simple SSL. It doesn't look like there are any problems uploading in such high volume, just downloading.
Now connect the SFTP/HTTPS drop area to a script that runs a bittorrent tracker, which then wraps it up, rolls out the torrent (with password protection, which is built into bittorrent; think about all of those member-only bittorrent sites out there), and hosts it. The server participates in bittorrent as the initial host but the seeders should catch up and distribute the load quite well.
Ogg Opus (open, royalty-free, not patent-encumbered audio) beats the pants off of HE-AAC (which, in turn, is superior to everything else at pretty much every level).
Wow! So much wrong in just a single sentence...
Opus is an IETF developed codec, based on CELT from Xiph.org, and Silk from Skype/Microsoft.
Ah, I thought Opus was under Xiph's Ogg umbrella. Xiph certainly hosts the new CELT+Silk project called Opus. Ogg is (afaict) the only container used by Opus (.opus is an Ogg file container). Noting those things, if you can refer to Vorbis as "Ogg Vorbis" then why can't you refer to Opus as "Ogg Opus?" I knew this was informal (though it is somewhat common) and did it mostly to concisely demonstrate its connections to Xiph (which most people know as "the ogg [vorbis] guys").
HE-AAC certainly isn't "superior" at "every level". It excels at very low bitrate encoding that sounds SOMEWHAT like the original. As you start increasing the bitrate (eg 96k), low-complexity AAC easily surpasses HE-AAC. And as you go to higher bitrates still (eg. 160k), temporal domain codecs can outperform any frequency-domain codecs, so Musepack will beat the pants of AAC, and even Opus.
You again caught me generalizing. Perhaps I was mistaken, but I thought AAC encoders capable of HE-AAC would automatically select which AAC codec to use based on the compression level and this is what I was referring to. I also should have said "roughly equal or better than" rather than "superior to" in that statement.
Regarding Musepack (MPC), that is an obscure format that was generally on par with Vorbis back in the day (but Vorbis has been improved a few times since then while Musepack has not). I'm gauging most of the surviving "next-gen mp3" codecs as largely equivalent at the 128+kbps level these days (though my personal preference, biased in part towards Freedom (and Linux compatibility), is for vorbis).
We don't seem to be getting quality listening tests for higher bitrates any more. Everybody is obsessed with super-low bitrate (so much so that they don't even try to find an mp3 baseline by which to state things are roughly equivalent to). I found a 64 kbps comparison which shows Opus narrowly beating Apple's HE-AAC for the lead. I'd love to see a thorough and up-to-date comparison of the major contenders at the 96, 128, and 160 kbps levels that also includes the lossless version as a baseline.
Still, low bitrate lossy audio quality is important, so Opus is a good choice for streaming audio and video. That's why Google chose it for their latest revision of WebM, along with their new VP9 codec that they claim outperforms HEVC.
That's odd, since WebM uses Matroska,which doesn't yet support Opus (though that's in the works). We'll see if Google can successfully make MPEG-LA obsolete. For that, we'd also have to compare VP9 to H.265 (Google noted VP9 was ~7% behind h.265 in Q4 2011) or perhaps wait for Daala or some Dirac-like wavelet codec to come out of left field (though wavelet compression has large hurdles, it is closer to how our eyes actually see).
I seriously doubt the MPEG / MPEG-LA organizations, and their members, will consider using a patent-free audio codec along with their heavily patent-encumbered video codec. Their business model is patents, and they'll chose an expensive and inferior option over a free one, any day. I'd expect HE-AACv2 to be the best you can count on for the foreseeable future.
Agreed. Hopefully that won't stop Xiph and Google from stealing the show.
Ogg Opus (open, royalty-free, not patent-encumbered audio) beats the pants off of HE-AAC (which, in turn, is superior to everything else at pretty much every level). Opus also streams better, capable of dealing with extreme low-latency demands associated with real-time uses like VoIP.
It is so common to see people talking about tweaking x264 to improve quality and compression, but there is a point where you're better off optimizing the other pieces; AC3 passthru is laughable contrasted to 6-channel vorbis (which I use in place of HE-AAC due to not having access to a quality AAC encoder on Linux). I'm still waiting for opus support in matroska (which is in progress) or something to supplant matroska as the prevailing file container.
There's also the patent question; will this be intentionally patent-encumbered the way MPEG standards tend to go (in which case they'll certainly connect it to HE-AAC), or will this be a somewhat more open standard (which lends nicely to Opus)?
What on-topic points have you made? What citations of efficacy? You can't just say "you're protected" and leave it at that. That's no argument.
I understand how hosts files work. You appear to have a clever system to work around the size limits and make it work efficiently. Great. How performant is your data against live threats? What's your miss rate? How does it compare to URIBLs? How do you deal with non-link threats delivered via email (e.g. 419, attached virus)?
ooh, the nutorious APK spammer, this time spamming us about anti-spam. hi. would you like me to rip you to shreds?
1. This would need to be run on your MX record (which likely isn't Windows...)
2. SMTP does not use DNS. You get a connection from a spammer, it dumps email content to you.
3. DNS lookups used by anti-spam don't actually resolve domains in links, they use third-party URIBLs.
4. If you're suggesting that some anti-spam engineer (hi) design a mechanism to use your hosts file as a URIBL, you're suddently competing with far larger indices that update every few seconds. Your flat hosts file updates... sorry, I don't see any updating capability on your ad site. The last engine update was 44 days ago.
5. Even URIBLs only have visibility into domains that have already been spammed, not new ones.
6. There is such a thing as a hosts file that is too big, making me dubious of how scalable APK really is at doing the next-to-nothing that it does.
7. You are proud of a program that merely manages a text file that consumes 37MB of memory? Why does your program even need to run after installation? It doesn't appear to get updates.
8. You spammed us to advertise your software. Great strategy.
If you're using SpamCop you might have noticed that more and more ISPs just bounce such reports... Contacting such ISPs via Facebook just gets you list washed (in my experience). The real problem, IMO, are the ISPs that just care more about paying customers than a whining geek bitching about spam.
I don't dispute any of that. SpamCop does not listwash and does not condone listwashing. (I can't speak for Facebook, but they do have a good presence at the last remaining anti-spam conference and they do care.) SpamCop is not really an enforcement mechanism because it has no legal weight. Responsible network admins will be notified, those who ignore or otherwise don't play fair won't. That's merely the first pass; there's also the blocklist. Not perfect, but at least there can be some repercussion (so keep on reporting! Even if it seems like it's not doing anything, we may just not be getting critical mass for action, which can change over time).
We're basically set up to plug right into a legal body for real enforcement. Hint hint.
You "opt in" whenever your RFID badge is scanned at a conference or buy a product online. That's why they're giving out so many "free" iPads at conferences.
Most businesses claim that they would be crippled by using confirmed opt-in. That's probably an exaggeration, but the next step to winning that iPad could merely be confirming the opt-in email notification (which is increasingly trivial due to email-ready smartphones).
You also need to consider international marketers, who aren't subject to most of these laws (and/or risk nothing by way of enforcement). They'll keep doing whatever they like. Beyond that, there's the straight-up criminals, and there's nothing stopping them from buying lists from shady (or legit) marketers, scraping emails off the web, or even walking through a conference with a homemade RFID badge reader.
I expect that this will probably be about as frequently enforced at the USA's National Do Not Call List.
I agree. It takes a substantial amount of infrastructure to merely facilitate a complaint-receiving mechanism let alone to act on it. (I would know, I work on SpamCop, and our "enforcement" consists of sending abuse reports to network owners and/or blocklisting IPs on the SpamCop Block List.)
A lot of spammers use fake unsubscribe links as a way of verifying your address and the fact that you read the message. Some questionable businesses have verification elements to their unsubscribe links that will note the fact that you visited the site but then due to a bug fail to process your unsubscribe attempt (thus netting the same effect).
I will sometimes unsubscribe from things, but that's because I want to see how successful it was (and I can deal with the trouble caused by attracting more spam). I do not suggest this for others. Use sites like myWOT to research the link before trusting it enough to follow it and perform the request. Use sites like SpamCop and KnujOn (and, if you're in France, Signal Spam, which has legal enforcement power) to report anything else as spam. All of those reporting agencies are tied to actual enforcement (in some way; KnujOn busts registrars, SpamCop informs network operators (and builds its blocklist), Signal Spam prosecutes if in France).
Thanks, that was a nice official response to a crackpot article that should never have made it to slashdot.
My read of that article was that nothing is really safe (which is true, but you have to be reasonable about these things) and that larger companies at least have accountability. It kindly forgets that this accountability isn't to users, it's to shareholders. DuckDuckGo protects against these larger companies, and DDG might just fly low enough under the radar to avoid the attention of the NSA.
Keep up the good work, Gabe. If you're in the SF area, I'd love to buy you a beer.
Another way in is through the standard payments portal. Once logged in there, you can go to Profile -> Account & User Information -> Marketing Preferences. This lets you opt out of direct marketing that they send to you. (Might as well take care of that while you're in there.) At the very bottom, below the buttons, is a link to "Update your privacy choices for External Marketing & Analytics reports" (which is the same cmpchoice link as above). Clicking it bypasses the login page since you're already authenticated.
And by "Mozilla's stats" I am referring to their internal benchmarking using Kraken (Mozilla/Firefox), Sunspider (Apple/Webkit), and Octane (Google/Chrome). Mozilla owns and operates Are We Fast Yet.com and has a nice JS performance over time comparing each JS engine.
Do note that this is just JavaScript and not the whole shebang, but these days, they're pretty close. The JS section of Tom's review uses one of these JS tests and has similar results (though they discard its findings). Tom's does conclude that Chrome beats FF handily here.
I'm pretty surprised to see Chrome beating Firefox handily in JS and HTML and memory efficiency and standards and security yet losing overall. Perhaps too much weight was put into the hardware acceleration piece? Perhaps Tom's forgot that FF startup isn't so good when you load lots of addons (as most do)? My reading of those is that Chrome is the clear winner... and I'm a Firefox fan (for usability, security, and privacy, mostly via addons).
Head of IT doesn't really need to know that much tech. His blind trust in his underlings might be an issue, but lack of technical skills is not really an issue
There is a minimum level of IT competency that leads to credibility as an IT manager, however... actual managerial skills? That's all about goals, deadlines, motivation, people, targets, and deliverables (among other things).
I think both pieces are underrated; managers need to at least be able to do a passable job (D or so by letter grades) at what their direct reports do, even if s/he is a bit rusty at it. Most (but not all!) of this likely comes from just understanding what's going on (how each project connects to the other, reading and reviewing issues, tracking direct reports to measure progress, etc). In addition to being mostly qualified to do direct reports' jobs, a manager must also be skilled at motivation, have some degree of charisma (be a "fearless leader"), be able to deliver on deadlines, and be able to navigate whatever internal politics and other bureaucratic nonsense that comes up.
The Peter Principle is a proposition that states that the members of an organization where promotion is based on achievement, success, and merit, will eventually be promoted beyond their level of ability
Hm, interesting. I like the characterization, and perhaps it explains my current employer's angle on promotions: step one is to excel and display mastery of your current responsibilities (the Peter Principle) while step two is to successfully operate at the level the promotion would award. This is especially useful to the employer in that they have such candidates working (or trying to work) at a higher level than they are paid. I don't think this works without step two.
It works even better when the promotion comes with a bonus to compensate for the time the worker "should" have been in the new position (so s/he doesn't feel taken advantage of).
(Interestingly, this step two isn't mentioned on the wikipedia article. Instead, its second corollary, which is basically the beginning of step two, states that training should happen before the promotion. Close, but not necessarily strong enough; knowing duties and being able to satisfactorily perform them are two different things.)
A lot of recent movies have kind of ignored sub-plots and development of non-lead characters in exchange for stunts and effects.
I'm a big Gaiman fan for his thoroughness in crafting worlds (the world is a character, the reader's view and understanding expands as the story progresses). His interest in this movie (... as an actor?) implies that the movie will also have this element.
What kind of movie will this be, action (effect) or plot (story)? Will there be the level of depth and plots within plots that can fuel the imagination beyond the story that unfolds within the movie, or will it be an effects-driven flick that keeps us at the edge of our seats?
We do love our big numbers, but there are limits to what our eyes can perceive in FPS. What does this mean for real world applications like video encoding and password cracking? How long do we anticipate having to wait for tech like this to get affordable? Also, how does this compare to the nVidia Tesla, the current gold standard in password cracking?
I saw only one reference to nVidia Tesla (and no references to password cracking or video encoding) in those reviews (@Tech Report), and it might be damning:
Speaking of things that don't matter much, Nvidia has decided to scale back the GTX 780's capacity for double-precision floating-point math. Double-precision support is built into the GK110 GPU because of the chip's compute-focused role aboard Nvidia's Tesla products. Real-time graphics basically don't require that level of precision.
Single-window mode has absolutely nothing at all to do with why the GIMP GUI sucks. Switching to single-window mode is actually worse, not better.
It seems like 80-90% of the complaints regarding GIMP's UI are from people who won't be satisfied with anything but a full Photoshop GUI rip-off (e.g. the way LibreOffice mimics MS Office; Gimphoto and the defunct GIMPshop get close on this front). Their top issue is (well, was) the lack of a single-window mode. To shut them up, given how trivial it was to implement, it was added. I agree with you on the fact that the mode doesn't improve the UX, but it does shut down the #1 complaint, which is something.
What else is (independently) bad about the UI? I started my graphics career on Paint Shop Pro (a plugin-compatible Photoshop knock-off that I actually preferred due to better use of the right mouse button) and was able to seamlessly upgrade to Photoshop given the similar UI. GIMP therefore had a steep learning curve for me, but I have grown to prefer it over time (though I still have to hold back from certain ~hard-wired PSP keyboard shortcuts).
I think the real issue here is merely that GIMP is not a Photoshop clone and image professionals aren't as proficient with computers as professionals of other industries that spend similar amounts of time on computers. They took a very long time (running through tutorials and perhaps paid classes) to learn Photoshop, and there are no equivalents for GIMP (at least, not with the same polish, which these users need), not to mention the fact that it's a serious time (and often monetary) commitment. The only solutions for these uesrs are to make GIMP bi-modal (GIMPshop mode) or to both improve overall computer proficiency (which is happening over time anyway) and create highly polished tutorials and professional courses on GIMP.
Even then, GIMP would still need to absorb (or better partner with) the features currently relegated to the Separate+ and PSPI plugins.
As I've said elsewhere in this article's comments, GIMP is not really professional-grade, it's just close enough for people to make the comparison. LibreOffice has commercial backing, as does the Linux kernel, as does WINE. Perhaps what GIMP "needs" is a commercial backer, that implements new features within a non-free plugin suite (and/or a fork that somehow gets around the GPL) and expands GIMP's base to maintain compatibility, even slowly trickling their commercial features into GIMP over time so as to merely represent what the Free Software version will get in a release or two.
Still no support for 16-bit per channel after all these years.
Isn't that implemented by the Generic Graphics Library (GEGL), partially implemented in GIMP 2.6 with a migration path that should end with GIMP 2.10 (the next version) fully utilizing it? 2.10 has been specifically noted as supporting 16 (and 32!) bits per color channel. That link, from a year ago, even has a screen shot. Still, 2.10 doesn't have a release schedule, and despite that the developers are committed to "shorter development cycles," it looks more like it's still a ways out (2.9, the dev pre-release, is still several months out at the earliest). Still, it's heartening to know they're on the right path (and that they've gotten around the design flaws that preiviously made this kind of feature impossible to implement).
The worst thing about GIMP is that its existence leads the FOSS community into complacency. People need to realize that there really is no good open-source competitor to Photoshop and start working on one, rather than pretending that GIMP fits the bill and then arguing with creative professionals who repeatedly point out why it doesn't.
Again, GEGL comes to the rescue. The whole point of it is to make it a library so it can be used from GIMP or any other utility. It represents that ground-up rewrite you so desperately plea for.
Regarding a professional-grade tool... Free Software never really offers that. You can get close, and sometimes you get lucky, but for the most part, there is no free ride. Generally, the best you can hope for is a commercial closed-source application that works well in an otherwise Free Software environment. It's icing on the cake when the vendor of such software offers a Free version of it (e.g. Codeweavers and Crossover vs WINE).
There's always "more" work needed, and for high-end items like the Photoshop features missing from GIMP, there's rarely enough community-driven (read: volunteer) time and energy to make it happen. It's worth noting when a major feature is missing, as car mechanics tend not to be racecar drivers (as mentioned elsewhere in the comments), but it's not worth complaining unless you're rolling up your sleeves and/or putting up a bounty to make developers' time easier to allocate.
That's a lot of money for space research. . Do they know something we don't?
What are you talking about? No it is not!
They use some of that money for manned space missions rather than for research. Still, their previous $3 billion annual budget could afford to send men to space while NASA's $18 billion annual budget apparently cannot. Now Russia announces a spending increase up to USD$68.71 billion over eight years (USD$8.59b a year), roughly half of what NASA's sliced up budget is currently.
Neil deGrasse Tyson's video pleas We Stopped Dreaming and its follow-up A New Perspective proposed we increase NASA spending to 1% of the US Federal Budget (current spending: 0.49%) suggests we could go to Mars and innovate the way we did in the 70s. That's significantly more than Russia's new investment and would help us keep our lead. Otherwise, we're losing both innovation and innovators.
I'd like NASA to be funded by the largest of:
* 1% of the US Federal Budget ($3.8t -> $38b in 2011)
* Half of the US DOD's Research, Development, Testing & Evaluation budget ($79b -> $39b in 2010)
* 5% of the whole US Military budget ($550b -> $27b in 2011, $708b -> $35b in 2012)
This extra funding would come from otherwise allotted military spending (so an increase to the military budget would typically increase NASA's budget as well). As I noted a few paragraphs earlier, this would roughly double the current $18b budget and would bring us to Mars.
For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.
So what your telling me is that they decided that a password that said user probably wrote on a sticky-note attached to their laptop or saved in a plaintext password is more secure than a ssh private key that MIGHT not be password protected?
If a user isn't going to properly secure an ssh private key, there is no way in hell they are going to properly protect a password!
I've been in IT. I've seen it first hand. These people do understand and have decently secured systems, but trade off security for convenience rather than learning ssh-agent, missing the point that their perceived "minor" security issue isn't as personal as they think and risks exposing things like code trees and proxies to would-be attackers.
My "solution" was to serve on an alternate SSH port, since they also didn't use ~/.ssh/config, so anybody stealing their keys would also have to troll their ~/.bash_history to figure out what the keys opened. I also walked around the office and emailed people with walkthrough instructions for using ~/.ssh/config and ssh-agent/Pageant (PuTTY's agent) on Linux, OS X, and Windows.
There are two (very ugly) "secure" solutions to this.
1. Draconian: The IT department requests the private key, tries to brute force access, then deletes it after a certain degree of failure. IIRC, pubkeys can be generated from private keys without passwords, so it's verifiable. Big snag: the user could remove the password later. As long as the private key is safely and securely submitted (say via an SSL form) and safely/securely stored during the brute forcing, this is as secure as your trust in the sysadmins (and/or your password strength).
2. Policy: enforce via required educational video or similar nonsense plus a legal contract. Best done in physical form since nobody actually pays attention to EULAs and whatnot. Can be combined with Draconian #1 above.
Nice! AuthorizedKeysCommand (introduced 2012/10/31) can do exactly what we need: Set up a script that (securely) logs key usage and e.g. deny any key that is older than 366 days (by first use or else filesystem timestamp) and hasn't been used in 90 days or for any user whose last login (regardless of which key) was over 60 days ago, with a list of exceptions (by key, not user).
That's still messier than something that can go right into the authorized_keys file as a parameter, but it would do the trick handily.
Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.
From the IT policy standpoint, there's no way of requiring that a key has a password. There are lots of people who don't understand (or otherwise care to use) ssh-agent and similar mechanisms, and there are lots of people who assUme that their own systems' security is sufficient and don't realize that it jeopardizes the security of the IT department's systems.
For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.
Slashdot Mirror
I haven't needed to bypass my Linux distro and install a vanilla kernel in over ten years. I can wait. If it hasn't been packaged by the major distributions yet, it also hasn't been widely deployed. There are some highly competent kernel package maintainers out there, and they're likely to catch a lot of things themselves.
Then there's the package release and its early adopters (Debian, for example, releases the latest kernels in Experimental and/or Unstable, letting them cook for a while). I typically pick up new kernels when they're in Debian Testing or Unstable (if I really want a new feature). This minimizes the chance of running into problems.
(note, this works best for people using standard hardware. ymmv regarding embedded or obscure devices)
BitTorrent Sync is not open-source software, nor do they appear to have plans to make it that. Maybe in time we'll have a F/OSS client for the protocol (though I don't know if they've even opened the protocol yet, so that might be an extra hurdle).
However, it may not be necessary; set up an SSH server (which gives you SFTP) for uploads, perhaps even use one of the myriads of HTTP file upload mechanisms and guard it with some simple SSL. It doesn't look like there are any problems uploading in such high volume, just downloading.
Now connect the SFTP/HTTPS drop area to a script that runs a bittorrent tracker, which then wraps it up, rolls out the torrent (with password protection, which is built into bittorrent; think about all of those member-only bittorrent sites out there), and hosts it. The server participates in bittorrent as the initial host but the seeders should catch up and distribute the load quite well.
Wow! So much wrong in just a single sentence...
Opus is an IETF developed codec, based on CELT from Xiph.org, and Silk from Skype/Microsoft.
Ah, I thought Opus was under Xiph's Ogg umbrella. Xiph certainly hosts the new CELT+Silk project called Opus. Ogg is (afaict) the only container used by Opus (.opus is an Ogg file container). Noting those things, if you can refer to Vorbis as "Ogg Vorbis" then why can't you refer to Opus as "Ogg Opus?" I knew this was informal (though it is somewhat common) and did it mostly to concisely demonstrate its connections to Xiph (which most people know as "the ogg [vorbis] guys").
HE-AAC certainly isn't "superior" at "every level". It excels at very low bitrate encoding that sounds SOMEWHAT like the original. As you start increasing the bitrate (eg 96k), low-complexity AAC easily surpasses HE-AAC. And as you go to higher bitrates still (eg. 160k), temporal domain codecs can outperform any frequency-domain codecs, so Musepack will beat the pants of AAC, and even Opus.
You again caught me generalizing. Perhaps I was mistaken, but I thought AAC encoders capable of HE-AAC would automatically select which AAC codec to use based on the compression level and this is what I was referring to. I also should have said "roughly equal or better than" rather than "superior to" in that statement.
Regarding Musepack (MPC), that is an obscure format that was generally on par with Vorbis back in the day (but Vorbis has been improved a few times since then while Musepack has not). I'm gauging most of the surviving "next-gen mp3" codecs as largely equivalent at the 128+kbps level these days (though my personal preference, biased in part towards Freedom (and Linux compatibility), is for vorbis).
We don't seem to be getting quality listening tests for higher bitrates any more. Everybody is obsessed with super-low bitrate (so much so that they don't even try to find an mp3 baseline by which to state things are roughly equivalent to). I found a 64 kbps comparison which shows Opus narrowly beating Apple's HE-AAC for the lead. I'd love to see a thorough and up-to-date comparison of the major contenders at the 96, 128, and 160 kbps levels that also includes the lossless version as a baseline.
Still, low bitrate lossy audio quality is important, so Opus is a good choice for streaming audio and video. That's why Google chose it for their latest revision of WebM, along with their new VP9 codec that they claim outperforms HEVC.
That's odd, since WebM uses Matroska,which doesn't yet support Opus (though that's in the works). We'll see if Google can successfully make MPEG-LA obsolete. For that, we'd also have to compare VP9 to H.265 (Google noted VP9 was ~7% behind h.265 in Q4 2011) or perhaps wait for Daala or some Dirac-like wavelet codec to come out of left field (though wavelet compression has large hurdles, it is closer to how our eyes actually see).
I seriously doubt the MPEG / MPEG-LA organizations, and their members, will consider using a patent-free audio codec along with their heavily patent-encumbered video codec. Their business model is patents, and they'll chose an expensive and inferior option over a free one, any day. I'd expect HE-AACv2 to be the best you can count on for the foreseeable future.
Agreed. Hopefully that won't stop Xiph and Google from stealing the show.
Ogg Opus (open, royalty-free, not patent-encumbered audio) beats the pants off of HE-AAC (which, in turn, is superior to everything else at pretty much every level). Opus also streams better, capable of dealing with extreme low-latency demands associated with real-time uses like VoIP.
It is so common to see people talking about tweaking x264 to improve quality and compression, but there is a point where you're better off optimizing the other pieces; AC3 passthru is laughable contrasted to 6-channel vorbis (which I use in place of HE-AAC due to not having access to a quality AAC encoder on Linux). I'm still waiting for opus support in matroska (which is in progress) or something to supplant matroska as the prevailing file container.
There's also the patent question; will this be intentionally patent-encumbered the way MPEG standards tend to go (in which case they'll certainly connect it to HE-AAC), or will this be a somewhat more open standard (which lends nicely to Opus)?
What on-topic points have you made? What citations of efficacy? You can't just say "you're protected" and leave it at that. That's no argument.
I understand how hosts files work. You appear to have a clever system to work around the size limits and make it work efficiently. Great. How performant is your data against live threats? What's your miss rate? How does it compare to URIBLs? How do you deal with non-link threats delivered via email (e.g. 419, attached virus)?
ooh, the nutorious APK spammer, this time spamming us about anti-spam. hi. would you like me to rip you to shreds?
If you're using SpamCop you might have noticed that more and more ISPs just bounce such reports... Contacting such ISPs via Facebook just gets you list washed (in my experience). The real problem, IMO, are the ISPs that just care more about paying customers than a whining geek bitching about spam.
I don't dispute any of that. SpamCop does not listwash and does not condone listwashing. (I can't speak for Facebook, but they do have a good presence at the last remaining anti-spam conference and they do care.) SpamCop is not really an enforcement mechanism because it has no legal weight. Responsible network admins will be notified, those who ignore or otherwise don't play fair won't. That's merely the first pass; there's also the blocklist. Not perfect, but at least there can be some repercussion (so keep on reporting! Even if it seems like it's not doing anything, we may just not be getting critical mass for action, which can change over time).
We're basically set up to plug right into a legal body for real enforcement. Hint hint.
You "opt in" whenever your RFID badge is scanned at a conference or buy a product online. That's why they're giving out so many "free" iPads at conferences.
Most businesses claim that they would be crippled by using confirmed opt-in. That's probably an exaggeration, but the next step to winning that iPad could merely be confirming the opt-in email notification (which is increasingly trivial due to email-ready smartphones).
You also need to consider international marketers, who aren't subject to most of these laws (and/or risk nothing by way of enforcement). They'll keep doing whatever they like. Beyond that, there's the straight-up criminals, and there's nothing stopping them from buying lists from shady (or legit) marketers, scraping emails off the web, or even walking through a conference with a homemade RFID badge reader.
I expect that this will probably be about as frequently enforced at the USA's National Do Not Call List.
I agree. It takes a substantial amount of infrastructure to merely facilitate a complaint-receiving mechanism let alone to act on it. (I would know, I work on SpamCop, and our "enforcement" consists of sending abuse reports to network owners and/or blocklisting IPs on the SpamCop Block List.)
Hi. I'm in the anti-spam business. You got lucky.
A lot of spammers use fake unsubscribe links as a way of verifying your address and the fact that you read the message. Some questionable businesses have verification elements to their unsubscribe links that will note the fact that you visited the site but then due to a bug fail to process your unsubscribe attempt (thus netting the same effect).
I will sometimes unsubscribe from things, but that's because I want to see how successful it was (and I can deal with the trouble caused by attracting more spam). I do not suggest this for others. Use sites like myWOT to research the link before trusting it enough to follow it and perform the request. Use sites like SpamCop and KnujOn (and, if you're in France, Signal Spam, which has legal enforcement power) to report anything else as spam. All of those reporting agencies are tied to actual enforcement (in some way; KnujOn busts registrars, SpamCop informs network operators (and builds its blocklist), Signal Spam prosecutes if in France).
Thanks, that was a nice official response to a crackpot article that should never have made it to slashdot.
My read of that article was that nothing is really safe (which is true, but you have to be reasonable about these things) and that larger companies at least have accountability. It kindly forgets that this accountability isn't to users, it's to shareholders. DuckDuckGo protects against these larger companies, and DDG might just fly low enough under the radar to avoid the attention of the NSA.
Keep up the good work, Gabe. If you're in the SF area, I'd love to buy you a beer.
I couldn't log in through the proffered http://www.att.com/cmpchoice link.
Another way in is through the standard payments portal. Once logged in there, you can go to Profile -> Account & User Information -> Marketing Preferences. This lets you opt out of direct marketing that they send to you. (Might as well take care of that while you're in there.) At the very bottom, below the buttons, is a link to "Update your privacy choices for External Marketing & Analytics reports" (which is the same cmpchoice link as above). Clicking it bypasses the login page since you're already authenticated.
And by "Mozilla's stats" I am referring to their internal benchmarking using Kraken (Mozilla/Firefox), Sunspider (Apple/Webkit), and Octane (Google/Chrome). Mozilla owns and operates Are We Fast Yet.com and has a nice JS performance over time comparing each JS engine.
Do note that this is just JavaScript and not the whole shebang, but these days, they're pretty close. The JS section of Tom's review uses one of these JS tests and has similar results (though they discard its findings). Tom's does conclude that Chrome beats FF handily here.
I'm pretty surprised to see Chrome beating Firefox handily in JS and HTML and memory efficiency and standards and security yet losing overall. Perhaps too much weight was put into the hardware acceleration piece? Perhaps Tom's forgot that FF startup isn't so good when you load lots of addons (as most do)? My reading of those is that Chrome is the clear winner ... and I'm a Firefox fan (for usability, security, and privacy, mostly via addons).
Head of IT doesn't really need to know that much tech. His blind trust in his underlings might be an issue, but lack of technical skills is not really an issue
There is a minimum level of IT competency that leads to credibility as an IT manager, however ... actual managerial skills? That's all about goals, deadlines, motivation, people, targets, and deliverables (among other things).
I think both pieces are underrated; managers need to at least be able to do a passable job (D or so by letter grades) at what their direct reports do, even if s/he is a bit rusty at it. Most (but not all!) of this likely comes from just understanding what's going on (how each project connects to the other, reading and reviewing issues, tracking direct reports to measure progress, etc). In addition to being mostly qualified to do direct reports' jobs, a manager must also be skilled at motivation, have some degree of charisma (be a "fearless leader"), be able to deliver on deadlines, and be able to navigate whatever internal politics and other bureaucratic nonsense that comes up.
The Peter Principle is a proposition that states that the members of an organization where promotion is based on achievement, success, and merit, will eventually be promoted beyond their level of ability
Hm, interesting. I like the characterization, and perhaps it explains my current employer's angle on promotions: step one is to excel and display mastery of your current responsibilities (the Peter Principle) while step two is to successfully operate at the level the promotion would award. This is especially useful to the employer in that they have such candidates working (or trying to work) at a higher level than they are paid. I don't think this works without step two.
It works even better when the promotion comes with a bonus to compensate for the time the worker "should" have been in the new position (so s/he doesn't feel taken advantage of).
(Interestingly, this step two isn't mentioned on the wikipedia article. Instead, its second corollary, which is basically the beginning of step two, states that training should happen before the promotion. Close, but not necessarily strong enough; knowing duties and being able to satisfactorily perform them are two different things.)
A lot of recent movies have kind of ignored sub-plots and development of non-lead characters in exchange for stunts and effects.
I'm a big Gaiman fan for his thoroughness in crafting worlds (the world is a character, the reader's view and understanding expands as the story progresses). His interest in this movie (... as an actor?) implies that the movie will also have this element.
What kind of movie will this be, action (effect) or plot (story)? Will there be the level of depth and plots within plots that can fuel the imagination beyond the story that unfolds within the movie, or will it be an effects-driven flick that keeps us at the edge of our seats?
We do love our big numbers, but there are limits to what our eyes can perceive in FPS. What does this mean for real world applications like video encoding and password cracking? How long do we anticipate having to wait for tech like this to get affordable? Also, how does this compare to the nVidia Tesla, the current gold standard in password cracking?
I saw only one reference to nVidia Tesla (and no references to password cracking or video encoding) in those reviews (@Tech Report), and it might be damning:
Single-window mode has absolutely nothing at all to do with why the GIMP GUI sucks. Switching to single-window mode is actually worse, not better.
It seems like 80-90% of the complaints regarding GIMP's UI are from people who won't be satisfied with anything but a full Photoshop GUI rip-off (e.g. the way LibreOffice mimics MS Office; Gimphoto and the defunct GIMPshop get close on this front). Their top issue is (well, was) the lack of a single-window mode. To shut them up, given how trivial it was to implement, it was added. I agree with you on the fact that the mode doesn't improve the UX, but it does shut down the #1 complaint, which is something.
What else is (independently) bad about the UI? I started my graphics career on Paint Shop Pro (a plugin-compatible Photoshop knock-off that I actually preferred due to better use of the right mouse button) and was able to seamlessly upgrade to Photoshop given the similar UI. GIMP therefore had a steep learning curve for me, but I have grown to prefer it over time (though I still have to hold back from certain ~hard-wired PSP keyboard shortcuts).
I think the real issue here is merely that GIMP is not a Photoshop clone and image professionals aren't as proficient with computers as professionals of other industries that spend similar amounts of time on computers. They took a very long time (running through tutorials and perhaps paid classes) to learn Photoshop, and there are no equivalents for GIMP (at least, not with the same polish, which these users need), not to mention the fact that it's a serious time (and often monetary) commitment. The only solutions for these uesrs are to make GIMP bi-modal (GIMPshop mode) or to both improve overall computer proficiency (which is happening over time anyway) and create highly polished tutorials and professional courses on GIMP.
Even then, GIMP would still need to absorb (or better partner with) the features currently relegated to the Separate+ and PSPI plugins.
As I've said elsewhere in this article's comments, GIMP is not really professional-grade, it's just close enough for people to make the comparison. LibreOffice has commercial backing, as does the Linux kernel, as does WINE. Perhaps what GIMP "needs" is a commercial backer, that implements new features within a non-free plugin suite (and/or a fork that somehow gets around the GPL) and expands GIMP's base to maintain compatibility, even slowly trickling their commercial features into GIMP over time so as to merely represent what the Free Software version will get in a release or two.
1. 16bpc (and 32bpc) (native, pending for GIMP 2.9+)
2. CMYK (Plugin, supporting GIMP 2.4+)
3. Single-window mode for GUI (native, GIMP 2.7.3+)
You only used one out of three, you guys are putting less effort into this as the years go by. Guess Gimp has been winning for a while now :)
Now who's not putting in enough effort? ;-)
Still no support for 16-bit per channel after all these years.
Isn't that implemented by the Generic Graphics Library (GEGL), partially implemented in GIMP 2.6 with a migration path that should end with GIMP 2.10 (the next version) fully utilizing it? 2.10 has been specifically noted as supporting 16 (and 32!) bits per color channel. That link, from a year ago, even has a screen shot. Still, 2.10 doesn't have a release schedule, and despite that the developers are committed to "shorter development cycles," it looks more like it's still a ways out (2.9, the dev pre-release, is still several months out at the earliest). Still, it's heartening to know they're on the right path (and that they've gotten around the design flaws that preiviously made this kind of feature impossible to implement).
The worst thing about GIMP is that its existence leads the FOSS community into complacency. People need to realize that there really is no good open-source competitor to Photoshop and start working on one, rather than pretending that GIMP fits the bill and then arguing with creative professionals who repeatedly point out why it doesn't.
Again, GEGL comes to the rescue. The whole point of it is to make it a library so it can be used from GIMP or any other utility. It represents that ground-up rewrite you so desperately plea for.
Regarding a professional-grade tool ... Free Software never really offers that. You can get close, and sometimes you get lucky, but for the most part, there is no free ride. Generally, the best you can hope for is a commercial closed-source application that works well in an otherwise Free Software environment. It's icing on the cake when the vendor of such software offers a Free version of it (e.g. Codeweavers and Crossover vs WINE).
There's always "more" work needed, and for high-end items like the Photoshop features missing from GIMP, there's rarely enough community-driven (read: volunteer) time and energy to make it happen. It's worth noting when a major feature is missing, as car mechanics tend not to be racecar drivers (as mentioned elsewhere in the comments), but it's not worth complaining unless you're rolling up your sleeves and/or putting up a bounty to make developers' time easier to allocate.
That's a lot of money for space research. . Do they know something we don't?
What are you talking about? No it is not!
They use some of that money for manned space missions rather than for research. Still, their previous $3 billion annual budget could afford to send men to space while NASA's $18 billion annual budget apparently cannot. Now Russia announces a spending increase up to USD$68.71 billion over eight years (USD$8.59b a year), roughly half of what NASA's sliced up budget is currently.
Neil deGrasse Tyson's video pleas We Stopped Dreaming and its follow-up A New Perspective proposed we increase NASA spending to 1% of the US Federal Budget (current spending: 0.49%) suggests we could go to Mars and innovate the way we did in the 70s. That's significantly more than Russia's new investment and would help us keep our lead. Otherwise, we're losing both innovation and innovators.
I'd like NASA to be funded by the largest of:
* 1% of the US Federal Budget ($3.8t -> $38b in 2011)
* Half of the US DOD's Research, Development, Testing & Evaluation budget ($79b -> $39b in 2010)
* 5% of the whole US Military budget ($550b -> $27b in 2011, $708b -> $35b in 2012)
This extra funding would come from otherwise allotted military spending (so an increase to the military budget would typically increase NASA's budget as well). As I noted a few paragraphs earlier, this would roughly double the current $18b budget and would bring us to Mars.
For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.
So what your telling me is that they decided that a password that said user probably wrote on a sticky-note attached to their laptop or saved in a plaintext password is more secure than a ssh private key that MIGHT not be password protected?
If a user isn't going to properly secure an ssh private key, there is no way in hell they are going to properly protect a password!
I've been in IT. I've seen it first hand. These people do understand and have decently secured systems, but trade off security for convenience rather than learning ssh-agent, missing the point that their perceived "minor" security issue isn't as personal as they think and risks exposing things like code trees and proxies to would-be attackers.
My "solution" was to serve on an alternate SSH port, since they also didn't use ~/.ssh/config, so anybody stealing their keys would also have to troll their ~/.bash_history to figure out what the keys opened. I also walked around the office and emailed people with walkthrough instructions for using ~/.ssh/config and ssh-agent/Pageant (PuTTY's agent) on Linux, OS X, and Windows.
There are two (very ugly) "secure" solutions to this.
1. Draconian: The IT department requests the private key, tries to brute force access, then deletes it after a certain degree of failure. IIRC, pubkeys can be generated from private keys without passwords, so it's verifiable. Big snag: the user could remove the password later. As long as the private key is safely and securely submitted (say via an SSL form) and safely/securely stored during the brute forcing, this is as secure as your trust in the sysadmins (and/or your password strength).
2. Policy: enforce via required educational video or similar nonsense plus a legal contract. Best done in physical form since nobody actually pays attention to EULAs and whatnot. Can be combined with Draconian #1 above.
In my opinion, this is the interest of the new authorizedkeyscommand. A sample usage is available at http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/
Nice! AuthorizedKeysCommand (introduced 2012/10/31) can do exactly what we need: Set up a script that (securely) logs key usage and e.g. deny any key that is older than 366 days (by first use or else filesystem timestamp) and hasn't been used in 90 days or for any user whose last login (regardless of which key) was over 60 days ago, with a list of exceptions (by key, not user).
That's still messier than something that can go right into the authorized_keys file as a parameter, but it would do the trick handily.
Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.
From the IT policy standpoint, there's no way of requiring that a key has a password. There are lots of people who don't understand (or otherwise care to use) ssh-agent and similar mechanisms, and there are lots of people who assUme that their own systems' security is sufficient and don't realize that it jeopardizes the security of the IT department's systems.
For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.