> You are attacking a straw man of 'wanting ununlimited [sic] choices' (nobody said they want that),

"As many ways as possible" - FlufferMutter

> Nobody was talking about keyboard shortcuts

I see above in this thread talk about ctrl-w, ctrl-F4, "cycle through windows using the keyboard ".

Seriously, if you want a powerful, fast interface that requires learning, the bash CLI is a thousand times faster than any gui. Try it out. GUI is all about being simple by putting the knowledge in the world, not in the head. That means showing the common, sensible default choices.

> you are attacking ...

It's a suggestion, for something you'll probably like, not an attack, silly. Don't tell me you're one of those guys who feels that if his first idea is ever imperfect, that makes him stupid, so he must defend all of his ideas from "attacks" rather than learn anything, or take any suggestions.

> Who cares whether a Unix is certified? Linux is the big daddy of the server rhythm these days

Linux has a huge installed base, absolutely. Most of my work throughout my career has been on Linux. We also know that GNU stands for Gnu's Not Unix. Linux is popular, and it's explicitly Not Unix. There is no guarantee your Unix software or integrations will continue to work on any particular version of any particular Linux distribution, as they try out a third init system in as many years.

So who cares about certified Unix? Two groups of people. People who have enterprise production systems running Unix software that MATTERS care. If you're running a payroll system for 10,000 employees and a glitch means missing a pay day, or perhaps ending up with the decimal point in the wrong place on everyone's pay check, certification of the whole stack is good. You can, at a cost, show that the software uses only official Unix apis, and will therefore run on any certified Unix. Similarly , regulators and such like certified components for similar reasons.

The second group is represented by alot of the systemd comments. Certified Unix means you have certain guarantees about how things (still) behave. You won't have important stuff changed out from under you, if you interface with the system as a Unix system, not as a Brand X version y.z system. Apple CAN'T fuck certain things up in the next version, systemd style, without losing their certification. That can be attractive to a lot of people.

The claim was that "advanced users" don't use Macs.
To reply "I use a Mac" would be pointless and not advance the discussion in any way, because it wouldn't tell you whether "advanced users" ever use Macs.

What does move the discussion forward is to show that some advanced users do in fact use Macs, so a relevant post must establish two things:
a) I'm an advanced user
b) I use a Mac

Point a is made quickly, and in an easily verifiable way, by mentioning where you can find my name on your system.

If you want ununlimited choices, where you can do anything from anywhere, any time, that's called CLI. I open a bash prompt and I can do millions of things in one step, without opening any new windows, navigating to any other location, etc. Unlimited choices. I do most of my work at the command line because that's what I like as well.

The entire point of a GUI is to present the user with the most relevant and common choices for the current task at hand, in an easy-to-use way, so they don't have to KNOW all of the choices available, they can SEE the choices available at the present time.

If you want to memorize arbitrary key strokes to get things done quickly, that's precisely what the command line IS. A GUI is the alternative, for people who want to visibly SEE the choices, not LEARN them.

Learning hundreds of arbitrary keystrokes and using them in a gui is like using a motorcycle to move furniture- precisely the wrong tool for the purpose you wish to achieve.

Here's a post a made over two years ago.

http://slashdot.org/comments.p...

Not very good at this internet thing, are you?

You're talking about me.

I've been a developer for 17 years. My name is in the kernel changelog. I've designed and built custom servers with power tools. I use Mac Pros for work.

It seems GP might think that Apple only makes iPhones. Mac Pros, which run certified Unix (OS X) are possibly the _best_ option for serious professionals. There are also a couple other companies making one or two choices in well-built hardware you can install enterprise Linux on, of course.

You're thinking of the iPhone and iPad, toys for people who don't care about control over their property, but perhaps do care about build quality, vs. Macs, which are powerful Unix computers.

I've been a developer for 17 years. My name is in the kernel changelog. I've designed and built custom servers with power tools. I use Mac Pros for work.

You're right that it's normally easy enough to find the answers to questions like "what high school did you go to?" I make that much more secure by secretly replacing "you" with "Barak Obama".* I don't enter MY high school, I enter Obama's. I enter Obama's mother's maiden name. So anyone who goes on my Facebook** to get answers will get wrong answers.

* I actually use another famous person, not Obama.
** You won't find much on my Facebook page, because I don't use Facebook. But if I did, it wouldn't show the answers I use.

The GPL requires that the program include an offer to provide the source code, either on a physical medium or on a server. It does NOT require that it be distributed via the same server or service that binary is on. v3 makes that very clear, saying:

        "the Corresponding Source may be on a different server (operated by you or a third party)"

Putting the binary on the App store and the source on Github is exactly what that covers - provided that in or "next to" the binary copy you make it clear where the source can be found.

Therefore, if you are distributing a binary via the app store, and distributing the source via FTP or Github, you're fine. v3 also says that you CAN distribute the source the same way that you distribute the binary, or you can distribute it using a different method. Also under either version of the GPL you can offer it on physical media.

So no, the GPL doesn't require that if the binary is delivered by mail (or app store) that the source be delivered the same way. In fact, it explicitly says the opposite.

The issue that FSF pointed out in another, more specific post, is that while Apple may not be required to do anything at all in order to conform with the GPL, they are in fact doing something. They are stating that all software distributed via the app store has certain restrictions. A more precisely fitting analogy, therefore, is post office policies about what can and cannot be shipped.

The FSF position is that the policy is an additional condition imposed by Apple which means that APPLE can't legally distribute GPL code under those conditions. That, however, takes us right back around to the question we started with. _I_ may distribute the software, as long as _I_ don't impose additional conditions. If I'm the one doing the distribution, it's legal. Apple is imposing additional conditions, but it's fine for Apple to have conditions on it's app store if they aren't the ones distributing the software. Just like the USPS has policies and conditions, which don't affect the fact that I can distribute GPL software by using USPS to do it.

Whether the person who put the app on the app store is distributing via the app store or if Apple is the one doing the distribution is murky. Viewing that phrase in isolation, a court could rule either way. However, the court will read the whole document, not just one phrase. The top of the GPL license says:

"Our General Public Licenses are designed to make sure ... that you receive source code or can get it if you want it"

Okay, so the purpose is to make sure you can get source code if you want it. That's the goal of the license agreement. Given the murky question of who is the distributor, a court should look at the purpose of the document. The purpose is to make sure people who want source code can get it. If it's freely available on Github and the app contains a link to that Github, the purpose is being fulfilled and the court should allow it.

The FSF post didn't say either what terms of the license they thought Apple was violating, nor why they think distributing via the app store is any different than distributing via the post office.

If I mail GPL software via the postal service, I have to comply with the GPL, which mainly means I have to include an offer to provide source code upon request. The postal service doesn't have to do ANYTHING regarding the license, they are a third party facilitating my distribution. It could be argued that Apple is no different- the person distributing via the app store needs to comply, Apple doesn't have to do anything to be in compliance.

By the wording of the license, it would be possible to argue either way, so a court would look at the INTENT of the license, it's PURPOSE. The gpl helpfully states it's purpose and intent right at the top - to maintain the four freedoms. As long as the freedoms are being maintained (by having source available, etc.), the court would probably rule that it's perfectly okay to distribute via the mail, ftp, email, http, or the app store.

Pdf is a subset of PostScript, a turing complete programming language. It's most often used for rendering documents, but is in no way limited to that. You can program an emulator in ps and run Linux inside your pdf. Gif and jpeg are not executable code. They are just (compressed) color VALUES).

There was one security hole in one specific executable LIBRARY which processes jpegs, but jpegs themselves are not executable and therefore essentially safe. Not so for pdf.

It is hoped that pdf is slightly safer than pure PostScript, but it's not FUNDAMENTALLY safer.

You make an excellent point. A corollary is a bit of a counter-point. Sometimes you DON'T need to decrypt it, and in those cases you shouldn't be able to.

The most obvious example is passwords. You store those as salted hashes which can't be decrypted. You don't need to know what their password is, you only need to know if it's the same as what they entered or not . We can apply the same principle to data we use for fraud prevention. We want to know if this transaction attempt is coming from the same device / os / ip / location that the legitimate user normally uses. We don't have to store their previous data, only a hash so we can see if the new attempt matches or not.

The OPM didn't need to store details of the applicants' past indiscretions. They could have simply encoded it as a risk score, 1-5. That's like a hash of the narrative, in a aay, irreversible but still useful. Then people couldn't be blackmailed or outed with the information.

The navy has been doing signals intelligence for a very long time. Ships communicate with their allied forces via radio using giant antennae, and they loiter close to enemy territory, and therefore enemy communications. It's only natural that they would point their large antennae at the enemy, and they've been doing so since just after radio was invented.

The navy also legitimately brings large numbers of personnel into foreign ports on a regular basis. It's only natural to give some of those sailors varying degrees of training in keeping your eyes and ears open while on foreign soil. Thus, the Office of Naval Intelligence has long been a significant part of our foreign intelligence capability.

The navy has been doing signals intelligence for a hundred years or so. Ships do two interesting things - they communicate with their allied forces via radio using giant antennae, and they loiter close to enemy territory, and therefore enemy communications. It's only natural that they would point their large antennae at the enemy, and they've been doing so since just after radio was invented.

The navy also legitimately brings large numbers of personnel into foreign ports on a regular basis. It's only natural to give some of those sailors varying degrees of training in keeping your eyes and ears open while on foreign soil. Thus, the Office of Naval Intelligence has long been a significant part of our foreign intelligence capability.

If you're underground or deep in a building, you're probably on wifi (or plugged in). That means we can geoip to within a 20 or 30 miles at worst, within a block in the best case (company IPs). That's far more accurate than we need to,know whether the acount holder COULD be there. What we're looking for is a transaction in southern California, folllowed 30 minutes later by one in South Carolina, then one in Mexico an hour later. We're computing whether it's possible for the account holder to travel that fast.

We then combine that other data points to score the likelihood of fraud. If it's card-present (swiped) that's lower risk than an internet transaction where they only have the card NUMBER, for example.