I like RenameMaster. Its UI is a bit clunky but it is easy enough to use and has tons of options in its "script editor".
Also, no installer.
I like RenameMaster. Its UI is a bit clunky but it is easy enough to use and has tons of options in its "script editor".
Also, no installer.
@Maciejasjmj said:
There's no way to browse pictures one-by-one in a folder, unless you've added them to a photo library. Browsing from a thumbdrive? Sucks to be you.
And if you (like me) keep your photos on a NAS that backs up to the cloud, you can add your (SMB) network share to your photo library just fine.
Oh, but the photo app won't actually read them from there. It just completely ignores that part of your photo library...
@Maciejasjmj said:
Zooming out goes like this: 130%-120%-110%-100%-your photo library.
At least it's not as bad as IE: What were they thinking?
Sounds like the classic mismanagement that all TDWTF readers are familiar with:
[S]enior officials repeatedly expressed doubts that the computer systems for the federal exchange would be ready on time... Deadline after deadline was missed... By early this year, people inside and outside the federal bureaucracy were raising red flags.
The Government Accountability Office... warned in June that many challenges had to be overcome before the Oct. 1 rollout.
Mr. Chao’s superiors at the Department of Health and Human Services told him, in effect, that failure was not an option... Nor was rolling out the system in stages or on a smaller scale, as companies like Google typically do so that problems can more easily and quietly be fixed.
Marilyn B. Tavenner, the administrator of the Centers for Medicare and Medicaid Services, and Kathleen Sebelius, the secretary of health and human services, both insisted in July that the project was not in trouble. Last month, Gary M. Cohen, the federal official in charge of health insurance exchanges, promised federal legislators that [the system would work] on Oct. 1.
Developers: We need more time.
Managers: LALALA, I CAN'T HEAR YOU! Failure is not an option! The project WILL roll out on [date]!
One person familiar with the system’s development said that the project was now roughly 70 percent of the way toward operating properly, but that predictions varied on when the remaining 30 percent would be done.
We all know what that really means. Ouch...
Others warned that the fixes themselves were creating new problems, and said that the full extent of the problems might not be known...
"These are not glitches," said an insurance executive who has participated in many conference calls on the federal exchange... "The extent of the problems is pretty enormous."
A round-the-clock effort is under way [to resolve the problems before the mid-December deadline].
Remind me: do massive government death marches ever end well?
Worried about their reputations, contractors are now publicly distancing themselves from the troubled parts of the federally run project.
(All quotes are from the New York Times)
Now updated with pretty printing! The error is still there (same resource), but now it pretty-prints the error in HTML!
Of course, the site still doesn't actually work...
@eViLegion said:
I'm not talking about the politics that cause this to happen. I'm talking about it being the default option.
You can't really separate those. It's the default option purely for political reasons. :)
The funny thing is, I used to work in government archives (before programming), and I have just a tiny inkling of the massive amounts of money that our government wastes every day on absolute crap. Whenever a "government shutdown" happens, the person-wanting-more-money (who is always the current person-in-power) makes sure to shut down the parts of the government that people will notice - so things like the national parks are first on the cutting block.
But that's completely unnecessary. There are countless[1] things our government is constantly doing that no one would (immediately) notice if they were cut, yet they continue right along during a "shutdown".
-Steve
[1] OK, it's not actually countless. I strongly suspect (but have not proved) that it's aleph-null. :)
Scaling and load testing are solved problems. If you pass a law requiring almost everyone in the country to buy something and then open the marketplace, you should expect (and plan for) scale.
Oh, and it's probably a bad idea to expose all your error details in a (very) public website.
@Ben L. said:
It compiles down to CSS, similar to how C++ compiles down to C.
While this was true in the 70s and 80s, it's certainly not true today. C++ today is never used to compile down to C (although I suppose it theoretically could).
You can view it without having to log in, unless something is blocking FB entirely. In that case, bummer, 'cuz this forum software is so... incredibly... horribly... awful that I wouldn't even try to duplicate the FB post here. Sorry!
So it's not just my state!
It seems that state universities tend to have some really poor CS programs. It's like they feel they have to have one, but have no idea what they're doing.
Oh, and the image is doctored. There wasn't a twitter logo in the original image. The penguins, though? That's real...
@DrPepper said:
@boomzilla said:Is there no way to incorporateUtilitiesHelper.GetUserByEmail(quuxInvited.Email) == null
into the original query / expression / filter (or whatever you call this)?Unfortunately not. Because you're going against a DB, the linq to sql converts your where clause into a sql statement, which is passes to the sql server to execute. If you add in a call to a function, that gets passed along to the sql server too, which obviously can't execute your code.
This has bitten me more often than I care to admit; and that's why the query needs to be done in stages.
Hence the AsEnumerable() method. At first glance, the AsEnumerable method appears to be completely useless, but it can be used to "step out of" the SQL context:
public static List<AdHocListHelper> GetAdHocUsersNotInSystem() { return DB.RetrieveAll<Foo>() .Where(foo => foo.QuuxEmail != null && foo.QuuxName != null) .Select(foo => new AdHocListHelper { FooName = foo.Name, BarTitle = foo.Bar.Title, Name = foo.QuuxName, Email = foo.QuuxEmail, Organisation = foo.Organisation.Name, FooId = foo.Id }) .AsEnumerable() .Where(quuxInvited => UtilitiesHelper.GetUserByEmail(quuxInvited.Email) == null) .ToList(); }
@blakeyrat said:
... especially now that every piece of hardware on Earth is little endian ...
As someone who has done a ton of development for custom hardware, I must take issue with that statement.
The CPUs used most commonly in desktop computers use a little endian memory interface, and serial ports and USB usually have configurable endianness, that is all. Cell phones, tablets, and most hardware components I can think of (Ethernet, CAN, SPI, FPGAs) are big-endian by nature.
If you work at the hardware level (e.g., one-bit-at-a-time transfers), big-endian makes a lot more sense because it's consistent. A few months ago I had to explain to a EE (programming an FPGA) that I would prefer the data in little-endian bytes with big-endian bits (which is what "little endian" really is). His "WTF?!" response was priceless.
-Steve (a .NET dev who became a firmware guy last year)
@pnieuwkamp said:
So, (at best) they're using reversible encryption instead of a hashing-function? Or do you just automatically assume they're storing them in plain text anyway?
As for emailing you your password, meh. Yes, in theory some man in the middle can grab a hold of a couple of passwords but what I'm really interested in is: How often does that actually happen? Each and every stoy in the news is about either losing USB sticks or having your database compromised, I hardly (if) ever hear anything about a mitm attacks in the wild.
It's not the man-in-the-middle attack that I'm worried about. I'm more concerned about what will happen when their password database gets stolen. (I say "when", not "if", because any company that talks about "securely" storing passwords like this doesn't understand security).
Once the password database is in hand, it's a simple matter to retrieve the passwords. They're likely storing them in plaintext or using some kind of rot13 obfuscation. If they are actually encrypted, then the attacker just has one additional step: retrieve the key - which is probably easy if they can get the password database. (This is the step that is prevented by storing passwords as a salted hash - even if the attacker got the database and all the source code for the website, they still can't get the passwords).
At that point, the attacker has everyone's password. And how many people do you know who use multiple strong passwords? Most likely, the majority of passwords in this database are the same passwords used for bank accounts. Bonus points if the same database has name and address information.
And that's why any company that emails your password in plaintext needs a security audit.
Saw this the other day on Twitter:
"@troyhunt Passwords are stored in a secure way. They’re only copied into plain text when pasted automatically into a password reminder mail."
http://twitter.com/UKTesco/status/229542141012107265