Typewriters are trivial to fingerprint. All of them have slight imperfections in characters, spacing, alignment.
A cloth ribbon would be hard to extract anything from, I'd think, maybe you could with a brand new one. Carbon film ribbons as used in the Selectric yes, you can easily read them but they can be shredded or burned to dispose of them securely.
I seem to remember it being mostly advertising even in the early 90s.
My thought on the headline was "and nothing of value was lost", but thats perhaps unfair since the last time I looked in one was probably 20 years ago.
Yep, I think we crossed that line with the release of Intel's Core2Duo line of processors. My 2010 MBA actually uses the C2D 2.13ghz, 4GB ram, and a 256GB SSD and it performs perfectly fine for 99% of my uses. Only time I feel bogged down is when I run multiple Play! Framework modules at once.
I remember when the first C2D benchmarks were released, it was hilarious at just how much faster they were than anything else around. Poor AMD hasn't recovered since...
There's enough security researchers (of any hat color) crawling over the Chrome binaries that I'm fairly confident there are no backdoors being introduced. To verify, you could disassemble the Chrome binary and compare it against a disassembled Chromium binary that you built. You could also use a packet sniffer and/or MITM proxy to verify that no unexpected data transmissions are occurring.
1. The probability of discovering something in all that binary code, especially with the intricate and non-orthogonal nature of x86/x64 assembly and odd compiler optimisations. This isn't some 80's game.
A comparison:
28500000 = Chrome binary size [1]
750000000 = Human Genome size (converted to bytes - 1BP = 2bits so 4BP per byte) [2]
So we're only 26x more complicated than Chrome and we have absolutely no fucking idea what is going on with us most of the time.
2. The probability of a vulnerability being published to Google versus selling it on the private market.
The actual comparison would be between the Chrome binary size and the Chromium binary size, which is quite small if you exclude embedded graphical resources.
I don't understand your point. If there were such a difference between Chromium and Chrome, then it would surely show up in a diff of the binaries' disassemblies. The size of the binaries doesn't matter, because (assuming you trust the Chromium source and your local system) only the difference between the two is relevant.
I said that the binaries could be diffed, then you responded that finding a difference is unlikely because the binary is very large. I don't understand what the absolute size of the binaries has to do with being able to compare them.
That probably depends on your definition of ‘backdoors’. Some of the data Chrome sends to Google could easily be considered a breach of privacy (and the corresponding functionality hence supposedly doesn’t exist in Chromium).
The Wikipedia page on Chromium[0] gives some differences, though my remark was admittedly mostly based on the description of the chromium package in Debian[1], which at least claims ‘usage tracking’ (and the generally useless and backdoor-like auto-updater).
True. But also true of firefox. But you can install chromium and firefox from source and be sure that apart from your compiler nobody planted anything in your browser.
And before someone else says this is bollocks, I've worked at a company with shared source access to Windows and there are still bits you can't get at like the CSP implementations so there may still be stuff like that in there.
No open review for any crypto functions in Windows is possible.
The Windows source code is the most comprehensively reverse engineered codebase in the world. Virtually every software security firm and every security product company has someone on staff who has the lay of the land for the kernel, services, and drivers. Even if Microsoft didn't publish most of the debug symbols for the OS, which they do, it'd still be the best understood closed source codebase in the world.
The likelihood of them hiding backdoors in software that you don't know about simply because some company you worked at that had access to some of their actual source code didn't have all that source code is low.
I don't understand your comment. Mine was a statement of fact. Your assessment of the information density of Chrome versus that of the human genome was comprehensively debunked.
I have been somewhat of a Google fanboy (alright, too strong-a-term, but you get the idea).
I encourage people to leave Google - because you know what? If enough people leave, Google will fight EVEN harder to stop blanket monitoring. When I hear Google scream from the top of their lungs "innocent until proven guilty" and "burden of proof required" then I will believe they are doing enough. Maybe Google should change it's background color to black?
Until then, I fully support anyone who looks for alternatives.
Nothing always works properly ("Perfect is the enemy of good").
A paper calendar and pencil simply doesn't scale if you need to share & sync calendar events with a team or group of people. Or simply want to keep your phone's datebook in sync with the one in your email client, etc.
It scales fine. In fact it scaled for hundreds of years before electronic calendars appeared. They mobilized two world wars with pens, paper and typewriters.
Synchronisation is not an issue if you have one single source of truth.
I get that you don't need a digital calendar. I've really not ever had that many issues syncing our team's calendars between mobile & desktop clients. Perhaps I've had good luck.
It seems your argument against a digital calendar holds for all the things you're seeking a non-Google replacement for. In light of that, do we really need email or blogs, or federated IM, for that matter? Write a letter instead.
Indeed. Paper calendars might have worked for WWI and WWII, but that took a lot of effort and was not instantaneous. I would also like to get up in the morning and not have to actively check the calendar to see what are my daily tasks -- rather, I would passively glance at my phone (or computer) and have it tell me what are my daily tasks. It's just less overhead to worry about, and freeing some brain cycles for whatever tasks you may have ahead. It's either lazy or efficient, whatever you prefer :)
I spent several years using outlook, apple ical and windows live calendar. I then ended up having to write a backend for icalendar protocol and saw what a shit crock everything is. It's a miracle any of it works.
Last year I moved back to a paper diary and a mechanical pencil. It is considerably more flexible, readable and editable. I hit several brick walls with computer based calendars particularly with having to add complex events like "every third Friday but not the 25th because I'm on holiday then".
Free form is sometimes better than structure.
Its like going from a relational database to a document store.
However there is one problem with typewriters people generally forget: you can extract everything that has been typed from used typewriter ribbons...