Slashdot Mirror

Describing the collection of anonymized data as spyware is dishonest and false for two reasons. First, it's anonymous so it can't be used to spy on anyone. Second, they are not hiding that they collect it; normally if you are spying on someone you don't tell them.

Aside from that it's just an overblow worry. People who have this concern typically have no problem using a smartphone or google products. They just use it as a flimsy prop for their anti-ms bias.

How do you know it's anonymized? How do you even know what information is being transmitted to Microsoft? It's encrypted. And clearly it's very valuable to Microsoft, because it conspicuously bypasses the user's hosts file and the firewall. And it's dispersed to over 100 domains, some of which you could possibly guess what it's for, but most of them in mystery.

Although Microsoft have publicly documented that you can't turn off the surveillance, the buttons in the OS which seem to turn it off is very misleading. Hence they are, in effect, hiding it.

My personal favorite is Google Play Music. I upload all my old songs, and subsequent new songs, using the gmusicapi Python module under the hood. I can then stream my music in my car while driving.

This gets into the details for the .NET Platform Standard and which versions of each official .NET implementation correspond to which versions of the standard:

https://github.com/dotnet/core...

It also provides a better system of dependency management (guard rails) when using a subset implementation.

Discussion thread about this: https://github.com/dotnet/cli/...

Blog post detailing the why, how, and what: https://blogs.msdn.microsoft.c...

The telemetry is only in the tools and does not affect your app.

The data collected is anonymous in nature and will be published in an aggregated form

You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.

The feature collects the following pieces of data:

• The command being used (e.g. “build”, “restore”)
• The ExitCode of the command
• For test projects, the test runner being used
• The timestamp of invocation
• The framework used
• Whether runtime IDs are present in the “runtimes” node
• The CLI version being used

Would this be the .NET from the same company that has been pushing spyware into millions of computers around the world and making it increasingly difficult to work out how to opt out?

Yes https://github.com/dotnet/cli/pull/2145.

So lucky it's open source then? Oh right, you're ready to throw open source under the bus for any opportunity to generate some Microsoft FUD. The answer here is to fork the project and/or don't accept the submission but ultimately -- as we have seen with systemd already -- the open source "community" is a bunch of do nothings who will bitch a little bit but ultimately suck down whatever is given to you. You claimed you needed source code and freedoms but as systemd and this have proven, you're just a bunch of lazy whiney cunts.

Proprietary?

Would this be the .NET from the same company that has been pushing spyware into millions of computers around the world and making it increasingly difficult to work out how to opt out?

Yes https://github.com/dotnet/cli/pull/2145.

When I heard about https://github.com/dnschneid/c... I got an inexpensive chromebook and ended up quite satisfied running Debian 8.4 a/k/a Jessie with xcfe in a chrooted envinroment under Chromium OS. I use it offline alot and it's fine. But it would be cool if there were a Peppermint crouton thingy for this because it sounds like it's well-suited to this type of use and my Debian, overall satisfaction notwithstanding, has some clunkinesses.

Here you go

https://github.com/tux3/qtox

Security + P2P style app. Windows, Android and Linux.

1) GCM client libs are open source. https://github.com/google/gcm You interact with GCM through a REST or XMPP API. You can trivially swap out GApps for one of the GCM-only alternatives, rebuild Signal, and point it to OWS's servers. (If you're building Signal from scratch and using it, rather than repackaging it and advertising it as something other than Signal, OWS is perfectly happy for you to point your client at their servers.)

Maybe OWS would agree with that, but would google? Is use of the GCM service legal if you don't have a valid gapps license?

Also, I don't really know where OWS draws the line, whether a howto posted somewhere on the internet how to download + build without gapps is okay, or whether pushing the modifications to a git repo somewhere is okay. At which degree does it become a separate "product"?

Also, if you donwload via git and build it yourself with your own modifications, then its surely harder to update than if you just download the updated version from some fork, which may be updated in a faster fashion. Lagging behind is the major critique points of forks by moxie.

Also, part of the reasons why OWS doesnt want an f-droid build of the app apply for "download from upstream git + do the modifications yourself" as well: you can always switch to older versions.

2) If you're concerned about traffic analysis, *anyone* between you and your conversation partner can snarf that data. Signal (and others) protects your conversation contents, not your addressing information. Thwarting a dedicated traffic analysis adversary is *very* hard, and Signal (and every other such messenger) has *always* claimed to protect only conversation contents, rather than addressing information.

I am not against sending addressing information to OWS, but I am against sending addressing information to google. It will end up in the government's hands any way, but OWS won't use the info for ad profiling and similar things. Google is fairly nice with the data of its users, but still i prefer to not hand it over in such a dependent way.

3) If you don't trust Google enough to send securely-encrypted data through their data shipping service, you should absolutely *not* be using an OS that they author. After all, GOOGLE HAS ROOT on EVERY Android image that they sign and has authored an ENORMOUS quantity of the code running as root in any Android image.

There is a difference between sending unique ids to a service which google owns, and using their operating system. I doubt that google has any reason to put backdoors or something into its source code.

Its the only messenger that:

1. can be used without gapps spyware
2. is halfway popular
3. has the source code released under a open source license
4. has authors who tolerate third party clients connecting to their server. This is not the case for Whatsapp, and also not the case for signal

Thanks to 1 and 3, telegram is available in the f-droid app store. This is why I use it, and I don't want to install software from third party stores like google play or sideload apps.

Yes, the encryption is not perfect, but I prefer that over having to install google spyware that would be required for signal for example.

what about noscript? https://noscript.net/

umatrix? https://github.com/gorhill/uMa...

Try Silence (former SMSSecure): https://github.com/SilenceIM/S... . It is a fork from TextSecure, the predecessor of Signal, and uses the Signal protocol over SMS. You still need phone providers, so technically you need servers, but you need no account and no registrations.

Silence can be installed via the FDroid app.

FWIW, Silence is awesome!

Of course it is true:

TorChat is a peer to peer instant messenger with a completely decentralized design, built on top of Tor's location hidden services,

You need a Tor Service to find your peer. How else would you find a peer?

Reading the wiki helps: https://github.com/prof7bit/To...

On the other hand, we talked about Phones, where IP adresses change constantly (actually they use a different protocol for addressing), Tor is for "PCs" only.

Try Silence (former SMSSecure): https://github.com/SilenceIM/S... . It is a fork from TextSecure, the predecessor of Signal, and uses the Signal protocol over SMS. You still need phone providers, so technically you need servers, but you need no account and no registrations.

Onion routing requires nodes, aka servers.

As we are talking about phones which get basically dynamic IP adresses all the time, it is impossible to have such a service without a central server infrastructure that knows who is online and how he is reachable.

That isn't true. Anytime you write "impossible", it should make you think twice.
Here's an example (I haven't used this, but I know this sort of thing is very feasible via Tor): https://github.com/prof7bit/To...

They are in git, indeed:

CVE-2016-4300: https://github.com/libarchive/...
CVE-2016-4301: https://github.com/libarchive/...
CVE-2016-4302: https://github.com/libarchive/...

append .patch to the url in order to get an apply-able patch.

But better update the whole library, usually there is lots of security related fixing going on when a security researcher takes a look at the code. Also, the git commit log may lie, and in fact some other commits fixed the issue, its just not marked this prominently.

The best policy is always to not copy the whole library into your source tree, but making downloading the library part of the build process. If you have to modify the library some way, its best to upstream those changes, but if you don't want to do it for some reason, or can't do it, then you can create patch files, and apply the patches as part of the build process as well. Updating the library then gets as easy as changing an url and rebuilding + checking that all the patches applied + retesting.

They are in git, indeed:

CVE-2016-4300: https://github.com/libarchive/...
CVE-2016-4301: https://github.com/libarchive/...
CVE-2016-4302: https://github.com/libarchive/...

append .patch to the url in order to get an apply-able patch.

But better update the whole library, usually there is lots of security related fixing going on when a security researcher takes a look at the code. Also, the git commit log may lie, and in fact some other commits fixed the issue, its just not marked this prominently.

The best policy is always to not copy the whole library into your source tree, but making downloading the library part of the build process. If you have to modify the library some way, its best to upstream those changes, but if you don't want to do it for some reason, or can't do it, then you can create patch files, and apply the patches as part of the build process as well. Updating the library then gets as easy as changing an url and rebuilding + checking that all the patches applied + retesting.

They are in git, indeed:

CVE-2016-4300: https://github.com/libarchive/...
CVE-2016-4301: https://github.com/libarchive/...
CVE-2016-4302: https://github.com/libarchive/...

append .patch to the url in order to get an apply-able patch.

But better update the whole library, usually there is lots of security related fixing going on when a security researcher takes a look at the code. Also, the git commit log may lie, and in fact some other commits fixed the issue, its just not marked this prominently.

The best policy is always to not copy the whole library into your source tree, but making downloading the library part of the build process. If you have to modify the library some way, its best to upstream those changes, but if you don't want to do it for some reason, or can't do it, then you can create patch files, and apply the patches as part of the build process as well. Updating the library then gets as easy as changing an url and rebuilding + checking that all the patches applied + retesting.

Websites should not store users' passwords. It's completely unnecessary. Instead, the registration and login web pages offered by the website should compute a hash of the user's chosen password using JavaScript embedded in the page. This hash should be sent to the web server, which must then store it. If the web server is subsequently hacked, the hackers get hashes of passwords rather than the original passwords. There's no way to recover the original password from its hash. So even if each website user chooses to use the same user id and password across many different sites, hacking one won't allow hackers to log into any of the others using the hacked credentials. An SHA-3 hashing algorithm in JavaScript can be as small as 1624 bytes of code - see blake32.min.js at https://github.com/drostie/sha...

I wish this were open source

It is open source, https://github.com/google/goog...

This is a successor to the ill-fated Turntable.fm. It allows you to queue and intermix youtube and Soundcloud playlists and listen to others play their playlists. The communities that have formed are really good at music selection, from 80s and 90s to chillout to progressive trance.

Also, the frontend is open source and they actively are looking for participation: https://github.com/dubtrack/www-dubtrack-fm

Pandora via the pianobar client at https://github.com/thedmd/pian.... Simple, works, doesn't use a lot of resources.

https://github.com/immunant/se...

More use of Plus+Codes! More use of Plus+Codes! Please add forward AND reverse lookups.

https://maps.googleblog.com/20...
Also called Open Location Code http://openlocationcode.com/

This is a great way to mark specific locations to a few meters or to a block or to a metro area. Just provide more digits to the codes to get more accurate.
https://github.com/google/open...

Humans without addresses need an easy way to share their location with sufficient accuracy, but not too much. What3Words has the right idea, but it is proprietary. GPS is completely open, but unuseable by humans.

Some engineers created Plus+Codes which include a resolution as more datum are provided. Google Maps supports plus+codes in the search box, but doesn't output those codes.

There are webapps and multiple language interfaces to libraries. The libraries are Apache licensed. Very business friendly.

https://github.com/google/open... has a nice explanation for why this is useful and needed. There are alternatives, but each is proprietary. Location should be freely available worldwide. Think about places like Nepal or Costa Rica where there either aren't addresses or they use addresses which apply to 50 other homes too? This is a big problem in the undeveloped world (though I wouldn't call Costa Rica or Kathmandu, Nepal undeveloped). There are places in rural USA and Europe where plus+code use would be very helpful too.

More use of Plus+Codes! More use of Plus+Codes! Please add forward AND reverse lookups.

https://maps.googleblog.com/20...
Also called Open Location Code http://openlocationcode.com/

This is a great way to mark specific locations to a few meters or to a block or to a metro area. Just provide more digits to the codes to get more accurate.
https://github.com/google/open...

Humans without addresses need an easy way to share their location with sufficient accuracy, but not too much. What3Words has the right idea, but it is proprietary. GPS is completely open, but unuseable by humans.

Some engineers created Plus+Codes which include a resolution as more datum are provided. Google Maps supports plus+codes in the search box, but doesn't output those codes.

There are webapps and multiple language interfaces to libraries. The libraries are Apache licensed. Very business friendly.

https://github.com/google/open... has a nice explanation for why this is useful and needed. There are alternatives, but each is proprietary. Location should be freely available worldwide. Think about places like Nepal or Costa Rica where there either aren't addresses or they use addresses which apply to 50 other homes too? This is a big problem in the undeveloped world (though I wouldn't call Costa Rica or Kathmandu, Nepal undeveloped). There are places in rural USA and Europe where plus+code use would be very helpful too.

Flash Player (PPAPI version) for Linux is current. Flash Player (NPAPI version) 11.2 for Linux is outdated but in extended support until May 2017, during which it gets security updates but no new features. Fresh Player is a wrapper plug-in for an NPAPI browser that hosts PPAPI plug-ins.

I tried Livestream with Safari 9.1.1 on OS X and it worked without having Flash installed. They're using HTTP Live Streaming which they can support in browsers which don't support HLS natively with hls.js (thanks to DailyMotion). So Flash is not a requirement for Livestream and they've got a pathway for dropping Flash from their site.

Most ad networks use much more than cookies & cache to identify you.

Flash cookies, user agent, screen resolution, installed fonts, plugins, etc.

Here's an open source library to do exactly that:

https://github.com/Valve/finge...

As yet, nobody has made an OS that isn't C at the bottom.

Pretty sure a lot of operating systems used Assembler at the bottom in the early 2000s. Now, I think they're pretty flexible, like:
https://github.com/CosmosOS/Co...

What a joke. If Microsoft was serious about this they should have done it...oh I don't know, maybe 25 years ago. You know, back when people were still writing applications in C, maybe?

Morons.

Yeah, none of this is written in C.

There is http://www.adeptus-mechanicus....

If companies were smart they would reset and ban all passwords in those lists and the most common password topologies, as listed here and here

For Android there's Tinfoil for Facebook, which sandboxes the Facebook mobile website and lets you allow or block location services. Their mobile website doesn't work all that well but it lets you access Messages without using Facebook Messenger. Google Play: Tinfoil for Facebook GitHub: Tinfoil for Facebook

The Snaps packages offer any advantages over AppImage + FireJail ?

https://github.com/probonopd/A...
https://github.com/netblue30/f...

The Snaps packages offer any advantages over AppImage + FireJail ?

https://github.com/probonopd/A...
https://github.com/netblue30/f...

You might be closer to the truth than you think. I was about to install snapcraft's ebuilds for Gentoo (snap-confine and snapd) but then noticed the systemctl calls and unit files. Adding insult to injury, they didn't bother to list systemd as a dependency. Hopefully there's not a real dependency on systemd and it's just a matter of writing init scripts, but in the meantime, thanks but no thanks.

You might be closer to the truth than you think. I was about to install snapcraft's ebuilds for Gentoo (snap-confine and snapd) but then noticed the systemctl calls and unit files. Adding insult to injury, they didn't bother to list systemd as a dependency. Hopefully there's not a real dependency on systemd and it's just a matter of writing init scripts, but in the meantime, thanks but no thanks.

Yes, they do still have SysV init. In fact, the other day I had to rescue a server I had just upgraded to Jessie and pick the SysV init "advanced" boot option in grub because systemd was silently shitting itself over a crypttab option it couldn't recognize (tmp=ext2 to format my /tmp partition with ext2 after assigning it a random key) and just sat forever in a loop counting up to 60 seconds over and over waiting for tmp_crypt to magically become mountable.

Reboot in SysV init and everything works (except for the constant errors from logging in, running su, logging out and so on that systemd and dbus were down). Naturally journalctl tells me there's no journal files. Apparently you can't see why systemd can't boot if you can't boot into systemd to get the journal file.

Did eventually find online that systemd does not support formatting temporary drives as ext2, you have to specify just "tmp" and systemd will decide what filesystem to create. Fixed it and now it works fine. Looks like it's only an issue on upgrading systems originally installed in a certain time range (the =filesystem option was added to crypttab in 2008 so older installs won't have it and I guess once the systemd writing was on the wall, newer installs stopped using it).

OxygenOS was developed by OnePlus, not the Chinese government. Unless you care to cite a source which shows otherwise, of course. The OxygenOS kernel is here if you'd like to go through it:

https://github.com/OnePlusOSS/...

how can we strategically pull the PERL language into the browser?

The Perl Foundation has funded a grant to extend Rakudo, the preeminent Perl6 compiler, so that it can generate JavaScript.
  http://news.perlfoundation.org/2016/02/ian-hague-perl-6-grant-applica.html

You can see the repo for the work here: https://github.com/pmurias/rakudo-js

and read updates from the developer's blog here: http://blogs.perl.org/users/pawel_murias/

This is why instead of embedding a plugin in the browser for PDFs, Mozilla has created PDF.js. It uses HTML5 & JavaScript to render PDFs within the browser's normal sandbox. There's even a Chrome addon.

Firefox implements PDF.js. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.

Chrome uses plugin called PDFium. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.

Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.

There are plenty of free PDF readers out there besides acrobat. One I have used at work is Sumatra PDF.

I can get free 1-year certs from StartSSL, so why in the world does anybody even use those?

And I'll keep mentioning StartAPI every time this BS about Lets Encrypt comes out - and point to my implementation of it in perl: https://github.com/CRCinAU/sta...

It takes 90% of the pain out of SSL renewals.

Here we go again...

- Rust is essentially a proprietary language, even if the source code is available.

I'd guess you say this because there is no standards committee for Rust? Well yeah, maybe that makes it "proprietary", but that isn't something bad. Linux has a dictator as well, just like many other projects. In the context of programming languages, at least Go, Java and Swift are "proprietary but open source" as well.

The great thing about open source is that if upstream fucks up, people create a fork. Think of LibreOffice for example.

- There is only one implementation of Rust. You're fucked if there's a problem with it. You can't use an alternative compiler, even temporarily, because none exist!

Does Go have an alternative compiler? Does Swift have one? This is standard for younger programming languages.

- The only implementation of Rust is very buggy (over 2,000 open bugs right now! [github.com]), despite it being written in Rust, which is a language that's supposed to make it harder to write buggier code!

This incredibly weird and wrong argument has been posted by ACs on slashdot for some months now. I'll just put this link here: https://news.slashdot.org/comm...

In fact, its a bad sign for Rust to have "only" 2k open bugs, more successful projects have even more bugs in their trackers than Rust.

- The "safety" Rust promises is only as good as the compiler that implements it, which as we can see from the over 2,000 open bugs is very questionable!

The major security benefits added by Rust are thanks to things people coding e.g. in C have to do themselves, like free()-ing stuff.
As with self driving cars, this added automation only needs to be better than human in order to be the better alternative, not perfect. And I'm sure Rust is inside that range.

- Rust isn't as portable as C++ and many other languages.

Most common targets are already supported: https://github.com/rust-lang-n...

You can't write an operating system in Go, but you can do it in Rust. In fact there is even a project writing one.

- Rust's syntax is mediocre, and it some cases it's worse than C++.

This is about taste. I like Rust syntax. If you don't like it its your problem.

- Rust's ownership semantics are inconvenient to use and difficult for many typical programmers to understand, even compared to C++'s RAII.

There is a high entry barrier, yes. But I think for people who are generally not accustomed to lower level languages like C/C++ its easier to not have to worry about stuff like allocation, and have the compiler say "this is wrong" if there is a problem, instead of stuff compiling but then failing horrendously or doing stuff like memory leaks or even stuff like race conditions, which only mean a problem in a fraction of the cases.

- Rust lacks proper class OO.

That's true. I can avoid it, for me its not a problem.

- Rust lacks proper exceptions.

I consider this a feature. Exceptions are one of the major sources of bugs in C++. Its much better to have the Result type, where you can recover from errors much faster. Recovering from errors is faster in Rust than in C++!

- Rust's standard library is inadequate and incomplete.

The standard library of C++ is far more inadequate and incomplete than Rust's. I am missing many functions I have available in Rust when writing C++.

Some nice stuff is marked unstable but you can use the nightly compiler if you want to use it.

- Rust's supposed benefits are typically no better than what

Are the problems with Rust really not obvious to you?

- Rust is essentially a proprietary language, even if the source code is available.

- There is only one implementation of Rust. You're fucked if there's a problem with it. You can't use an alternative compiler, even temporarily, because none exist!

- The only implementation of Rust is very buggy (over 2,000 open bugs right now!), despite it being written in Rust, which is a language that's supposed to make it harder to write buggier code!

- The "safety" Rust promises is only as good as the compiler that implements it, which as we can see from the over 2,000 open bugs is very questionable!

- Rust isn't as portable as C++ and many other languages.

- Rust's syntax is mediocre, and it some cases it's worse than C++.

- Rust's ownership semantics are inconvenient to use and difficult for many typical programmers to understand, even compared to C++'s RAII.

- Rust lacks proper class OO.

- Rust lacks proper exceptions.

- Rust's standard library is inadequate and incomplete.

- Rust's supposed benefits are typically no better than what you get when using C++11 or C++14, and modern C++ techniques.

- Rust's community, and it's strict (yet contradictory and hypocritical) Code of Conduct, make normal people feel very uneasy. No other programming language community goes so out of its way to police and control people like the Rust community does.

- Valid questions and legitimate criticism about Rust at discussion forums like Hacker News and Reddit are immediately met with oppressive and unjustifiable downvoting, likely done by the contributors to Rust who frequent those forums.

- Most Rust libraries are woefully incomplete, and many don't even compile properly with recent releases of the compiler.

- Nobody of significance is using it for anything important. The most notable users are Mozilla and Dropbox, neither of which is significant. The other users of Rust are minor and irrelevant startups, or weekend hobbyists. Languages like Go and Swift, on the other hand, are seeing widespread use by significant organizations like Google, Apple, IBM and others.

- Most of the hype around Rust is unsubstantiated.

- Rust's documentation is often less useful than it should be.

- Some of Rust's core contributors jumped ship from the Ruby community after it became clear that the hype surrounding Ruby and Ruby on Rails was wearing off.

- Servo, which is one of the flagship development efforts using Rust, has been progressing very slowly. Even if Rust isn't hindering Servo's speed of development, it apparently is not helping at all, either!

I'm sure there are more problems that I've forgotten to list.

It's very worrying that you accuse others of not knowing Rust, when it appears that it is you who does not know it well enough to understand its problems!

Any programming language with that many severe problems, especially when it has pretty much no users, should be considered a failure in my opinion.

If I understand correctly, Mozilla is re-writing their layout engine in Rust, which should be considerably more secure than Blink (Chrome's engine). But that's still in alpha stage.

I keep seeing comments like these, and they're clearly from people who have never tried Rust nor Servo.

Sorry, guys, but they aren't what they think you are! I encourage you to try them out for yourselves to see what I mean. Don't just rely on hype you read somewhere.

Rust's one implementation is riddled with bugs. See for youself! There are over 2,400 open bugs right now, and that doesn't include the many thousands that they've supposedly fixed in the past.

If Rust is supposedly "secure" and good for writing robust software, then why is the Rust implementation and standard library, which are written in Rust by the people who designed Rust, so buggy? Don't give me excuses about it being "complex" or "new", either.

How are average programmers supposed to benefit from Rust if those who know it the best are creating buggy code using it?

And then there's Servo. Where to begin, where to begin! It's nowhere near ready for any sort of usage. Try it for yourself. Please do it! See how awful it currently is. It's probably 15 years behind the other browsers. Will it manage to make up those 15 years any time soon? I really doubt it! Will it be able to then surpass the other browser engines, which obviously won't be standing still either? I really doubt it!

I'm truly scared for Mozilla's future. Firefox is losing users left and right. Rust and Servo aren't accomplishing much. And worse than that, we have people like you who seem to think that Rust and Servo are some glorious saviors, when realistically they're probably just wastes of time and effort.

Well, tough luck. What Netflix is doing here is battling this: https://github.com/ab77/netfli...

For awhile, used Steve Gibson's Perfect Passwords page - https://www.grc.com/passwords....

Then decided to go in-house - eavesdropping on an SSL connection? That's possible? ;)

Started with this script: https://gist.github.com/tylerh...

Changed it up a little so I could pass a number (otherwise it defaults to 63 chars), removed the limitation of zero vs upper-O, number one vs lower-L, etc. (didn't make sense as I'd just be pasting anyway), and put an alias in my bash init so I could call it without typing .php every time.

Decided never, ever to use a password on more than one site.

Of course, if I lose the password file, I'm screwed.. ;)

Use a variation of it to generate alpha-numeric folder names (say, for a Laravel code folder, or many other uses).