I have zero issue with this, and it's clearly labelled and explained. Of all the breaches in my privacy, this isn't one I'm worried about. Google gets 100% of my searches and email messages, so it's a question of who you trust.
To each his own, but I just want to point out that your examples of web searches and email require that SOME third party be involved because they are, by definition, attempts to reach a computer somewhere else on the internet.
In contrast, searching the local files on one's own computer or launching applications on one's own computer are private, local events that need not be shared with any third party.
Inherently private stuff just happens to leak out into the world now because Spotlight does web search too.
Everything you put on your computer should be assumed to be public the moment you connect to the internet. With air gap jump technology starting to become proven, you should assume that all digital content is public. To think otherwise is hubris and stupidity all wrapped up with a tiny little bow. Every company and government agency has been compromised to one degree or another, and targeted attacks are 100% effective given even slight competence on the part of the hacker. I've been around since before the modem, I've seen everyone hacked.
Regardless, it doesn't matter. It's simply ignorant to bitch about this, when the NSA literally intercepts all of this and exploits or introduces exploits into the software you use. This is fact. Apple at it's worst will present you an advertisement, big fucking whoop. Seriously, what is the risk? Annoyance? The NSA can wrap you around a pole and make it appear you were snorting 12kilos of coke a day. I am quite literally baffled by the sentiment on HN when I see people up in arms over convenience like this trumped up as if it were in violation of your rights. They added a 'learn more' link and explain what is going on. Yet the same people simply ignore the actual threat, repeatedly. Cowards.
Keep fighting them windmills. Because the real enemy fights back.
Is this where we are now? Patting Apple & friends on the back for sneaking in just a little bit more data scrapage, because surely the only people who think they have a choice are just idiots?
I'd rather be an idiot who gets angry about his TV phoning home to report every DVD and .avi file I've played (in the clear, for no apparent reason: there are no ads, recommendations or features of any kind on the set itself) than a defeatist who equates the futility of circumventing state surveillance with the futility of paying attention to one's outbound internet traffic.
I should have an active choice in how and who I expose my data. If LGe, Apple and friends can't be bothered asking people if they actually want their habits recorded, let alone bother to encrypt said data, expectations on storing, securing and using that data aren't exactly high.
It's not an irrational thing to weight the risk of state surveillance rummaging through my gmail to be a little less than some stupid home computer/router/NAS "feature" exploding and blowing me wide open to identify theft and financial fraud.
You do have a choice, thats why there is the ugly text with the learn more link. They really went out of their way to ensure you were informed. Anything less than acknowledgement stinks too much of either the tech cults, or unfounded paranoia. The first icon presented is Safari, so if you don't read and don't look at icons, then okay... But that's not Apples problem. If it's a feature you don't want to use, don't use it, you can turn it off without a python scripts. I tire of these stupid games.
Theft and financia fraud? Do you search for you account numbers and passwords in spotlight???
What prompted me to reply was when you said "Regardless, it doesn't matter. It's simply ignorant to bitch about this, when the NSA literally intercepts all of this and exploits or introduces exploits into the software you use".
When RealPlayer was grilled for bundling spyware which harvested the exact same data, why did their excuses ("hey we mentioned this in the EULA, plus you could've scrolled through the features and disabled it at install-time") not create the same placated reactions Apple seems to be achieving here?
"Opt-out of some part of this avalanche of b.s. information-leaking features serving little to zero actual benefit to the user" has always been a stupid, sleazy trend to monetize the very basics of computing and whilst I respect that most people don't give a damn and/or don't have the energy to give a damn, it's a user-hostile design pattern.
I switched to DuckDuckGo for the last couple of months. Works fine for 95% of my searches. The other 5 percent is related to local (to my country in Europe) searches, where Google is absolutely giving better results.
The other comments at this level saying Vagrant spins up a full VM are incorrect. Vagrant will spin up boot2docker if it isn't running (which Fig requires as well), and then just execute Docker to run containers. On Linux, Vagrant doesn't spin up a VM at all; it just executes Docker directly.
I'm not here to talk about Fig vs. Vagrant, since I think this thread should be about congratulating Fig to 1.0, but I did want to make sure that some facts aren't incorrect.
Right, I really phrased that poorly. I use vagrant on a windows machine in the office and various macs at home. Without the LXC, fig & docker don't really provide anything above what I'm using. Were I to move to linux, then this would have some advantages. Thanks for the clarification and a fantastic product.
Fig is a tool written in Python specifically designed to orchestrate groups of docker containers. It does not require virtualization by default, it talks directly to the Docker API (so you can use it directly on Linux without boot2docker/VirtualBox). It is useful because previously people were writing their own custom little Bash scripts etc. to bootstrap containers for e.g. a PHP app to run app code, a MySQL database, a redis instance and an instance of nginx to serve static files which are all meant to be tied together and work together in a specific way. One of the goals of docker is "one concern per container" so this helps people to use it in the right way and you don't have to, say, restart your database to restart your app (like you would if you crammed them all into one container).
Vagrant is a general purpose tool for automation and management of virtual machines written in Ruby. You specify configuration in Ruby. One of its goals is choice, so it has swappable "drivers" (so that you can use different hypervisors such as VirtualBox, Fusion, and HyperV) and "provisioners" (for installing software etc. when you bootstrap a new VM). I'm afraid I have to plead ignorance on the Docker provisioner, but mitchellh is the creator so I'm sure his input is sound.
the concept is the same as Vagrant. but it's substantially faster. when you `fig up` your app, it spins up almost instantaneously because it's backed by Docker.
Similar ends, but different means. Vagrant would launch a full-blown VM (likely on the order of several minutes), whereas fig'ing will start a container (on the order of a few seconds).
I've known about this for a while, though I don't remember my source. I seem to recall that it was first envisioned under Jobs, and AT&T started swinging punches when they caught a whiff. Although the source appears solid in hindsight, I chalked it up to a subterfuge project. Can anyone who has since left confirm this was the same initiative?
I always dislike the negative comments in Show HN, but I have experimented heavily with writing code on mobile devices, and there are much bigger issues than the editor. This may be a good product, the screenshots look good (though the same number of people buying the app as the number of current upvotes on HN, so that looks fishy as all hell). Regardless, the form factor just isn't suited to content creation, and nothing in the description or screens addresses this.
I agree with you, but the folks who made this app clearly don't.
The fact that these devs put so much time and energy into making something that I cannot imagine wanting to use for the reasons you describe makes me think that I have a very different relationship to my mobile devices than some other people do. Another example in the same vein is typing emails or docs. I don't ever type anything longer than a couple of sentences unless it's extremely urgent. But there are many people who don't seem to mind one bit!
I think the developers use Asus Transformers (tablets with associated keyboard docking stations that turn them into de facto laptops) extensively, so having a full IDE that can run on one of those would indeed be a boon -- even if most Android users have little use for it.
But why?? The point is that I would never choose to do development on a smallish device. In fact, I would always choose the largest, most powerful device available! Multiple screens, speakers, lots of ports, power, etc.
Maybe there is a market for commuters/travelers? Even then, I would prefer a large-screen laptop.
Regarding typing, I think a lot depends on the keyboard you are using. With default keyboard, yeah there's no way I'm typing more than a couple of sentences, as you said.
But with a better keyboard (e.g. Swift on Android), I can easily type a few paragraphs. Because text prediction and spelling correction is so damn good, I just need to press the keys roughly near the one I intended (e.g. jekko -> hello).
Although, I could type natural languages, there's no way I'd be typing code. Simply the number of special characters required makes it very slow and frustrating. And if you need to be mobile, you can just buy Chromebook (or similar device), install Ubuntu/Arch/whatever and happy coding.
The form factor of what? I could be sitting in front of Android running on a 21-inch display using a normal keyboard and mouse. And the CPU behind it might be the same one that usually runs OS X or Windows.
Guess, parent meant form factor of a typical mobile Android device. An external display and HID devices aren't mobile.
Yes, I know, one could move their phone between docks and that would be mobile, but bet this is a very rare case. If one has stationary terminals, I think it would be very unusual if they're used solely as a dock station — one's likely to also have a stationary computer attached to them.
I have a 12 inch tablet with a bluetooth keyboard and mouse, its perfectly good for content creation, it comes with an office clone that makes creating docs a snap.
I have been using a bunch of editors, and while many of them are great the mostly suffer from 3 main problems.
1. Capacity, most can handle a 200 file project, but they sieze up solid much beyond that.
2. Git and github integration is often poor, for some reason they all get ocd about dropbox and google drive integration, but fall apart on git or svn integration.
3. They need a good ssh client embedded, both to provide sftp capability, and to allow you to have one click access to your dev, staging and production servers.
>I could be sitting in front of Android running on a 21-inch display using a normal keyboard and mouse.
Do you refer to some future possible Android or to the Android of today?
On a good day, how many people interact with Android with a mouse and without a touch screen to get real work -- programming or writing, say -- done? If your answer is more than a handful, then I'd like to ask you how you know that.
I've messed around with coding on mobile and basically came to the conclusion that it's only practical for emergency situations or making very minor tweaks. But in an emergency situation it can be extremely valuable to be able to make a quick fix while you're traveling without a computer. Even if it is a little tedious to work on the device.
So for that reason I'm happy to see mobile development tools being made, even if I don't plan to use them day-to-day quite yet.
I wouldn't have wanted to program on it, but as a writing environment, it was fine. Now give me writing software of the same quality as WordSmith, a keyboard as good as the Stowaway, and my ho-hum Galaxy S3 with its 5" hi-res color display and a quad-core 1.5GHz CPU...
I'm curious what the bigger issues you've experienced are. I've never done any serious content creation on a mobile device, but the obvious issues that come to my mind are lack of keyboard and mouse, and the responsiveness of the UI. Presumably, those can be addressed or mitigated through hardware. Are there issues that go beyond that?
Well, the lack of a keyboard and mouse and the lack of an intuitive way to solve these problems in a mobile device. These comments seem to imply that I can add hardware and the problem is solved. If I add hardware, I no longer have mobile on the go development, I have a bag of crap that makes this less convenient than an air or ultrabook. Now if someone invents a way that eliminates the need for the keyboard, then I'll use it with glee. But this product is a desktop app on a mobile device and does nothing to really innovate in the space. I want this to work, but it isn't as simple as writing a desktop app on android.
The issue for me is that every app was modal. Even when playing around with Windows/Android split screen views, they just aren't as productive as a windowed system for me.
There is nothing about phones that make them inherently bad for content creation. Sure, they just tend to have more support for consumption use cases (which is what makes them great IMO). But I think it's only a matter of time before they reach of good enough point to use them as the primary tool for productivity.
>>though the same number of people buying the app as the number of current upvotes on HN
I believe those downloads are for first few hours since the app is only 1.5 days old. Play Store Install numbers are typically 1-2 days old and app was launched on October 14th.
Does anyone know of a reasonable deployment management solution in open source for .Net? Octopus is perfect, but with my limited budget of $0, it's a tad costly.
I haven't used it yet on Windows, but it's good enough on unixes... And it's quite lightweight and easy to setup (it relies on python2 on *nix and powershell on windows)
It is a linux tool primarily, but I'm one of the comaintainers of the saltstack salt config management tool. It supports windows pretty well and we have plenty of users who use it on windows for their enterprise server deployments.
It can be used to replace deployment tools like capistrano and fabric on Linux. No reason it can't do the same on Windows if you grok it enough to use it.
I hate this sentiment. I speak English and French and have limited amount of time to hack on software I'm giving away for free. My day job consists entirely in English. I have neither the experience, nor the inclination for internationalization of software. Don't like, don't use it. Or fork it, and add it yourself, because obviously you have more free time than I have.
> I have neither the experience, nor the inclination for internationalization of software.
Taking a piece of software and making all of the UI language localized is one thing. Making sure that your program doesn't blow up if it encounters UTF-8 is another thing. Nowadays if your program chokes on UTF-8, I think it's safe to just consider it broken.
In any case, looks like this is really where the issue may lie:
# for non-English characters
def getRealLengh(str):
length = len(str)
for s in str:
if ord(s) > 256:
length += 1
return length
and:
for val in shn.row_values(n):
try: val = val.replace('\n',' ')
except: pass
val = isinstance(val, basestring) and val.strip() or str(val).strip()
line += val + ' ' * (30 - getRealLengh(val))
vim.current.buffer.append(line)
In accounting for the fix-width layout of non-ASCII characters.
Are UTF-8 encoded Excel documents actually common? Do they even exist? I thought Excel used CP 1252 on English Windows and the corresponding code pages on other language versions?
There are two types of formats generally recognized as XLS: Excel 5.0/95 "BIFF5" and Excel 97-2003 "BIFF8". The former uses a language-specific codepage like 1252 and the latter can use a language-specific codepage or the more general 1200 (UTF16LE).
I'm pretty sure that xlrd decodes it all to unicode() in Python, so that should be a moot point. You would only need to worry about passing it as utf-8 to Vim at that point.
Excel 97-2003 (XLS) actually uses UTF16LE in that case, not UTF8. Excel 2007+ XLSB exclusively uses UTF16LE -- there is no way to force it to use a codepage
Consider this: A medical device that people's lives depend on. It only fails in 1/1000 cases causing death. Many people could state, "it works for me, can't be broken!" On the other hand, the families of the dead could argue that it is broken. Who is right?
Obviously this isn't such an extreme case. No one has their life depending on a Vim plugin, but it illustrates a point. "Works for me" doesn't necessarily imply "isn't broken."
I think the point is that for many people building free software for fun, "works for me" is all that matters. Testing use cases that you know you will never encounter is not interesting or challenging (at least in this case), but it takes time, and you're not making a product, nobody is relying on you. Why bother?
The author of this plugin isn't trying to make a spreadsheet competitor, they just released it publicly because other people might find it useful or interesting.
We can consider it incomplete, or disagree with the design choices, but broken means it doesn't do what it's supposed to do. Here, it does everything the author intended it to do, and everything the description says it does. When you say it's broken, it sounds at least to me like you're imposing your own requirements on a project you have nothing to do with. It's like calling Microsoft Office broken because it can't handle Open Office files. It's not broken, it just doesn't have all the features you would have included.
Perhaps you could take into account that emoji and other fancy characters are heavy utf8 characters. UTF support doesn't usually mean "prepare for Swahili", but more "don't choke on the characters"
the thing is if you build for unicode support from the start these conversations don't need to be had. The problem is not enough people treat text as a black box from the start (I can understand unwillingness to support bigger things like RTL)
Okay... let's go into this... how are the strings in excel encoded anyway?
I'd be willing to bet money that at least some of the formats in question aren't UTF-8, they are likely ASCII encoded against a character set or code page.
Then you have to read that codepage, and convert the necessary characters to their Unicode equivalents, and from there do you downcode to utf-8?
Does the language this library is written in support that translation? Are there modules to do that? Is the license for those module(s) necessary compatible?
Who's going to go through the different document versions to confirm, and adjust for the various encodings for non-ascii characters?
It's not as simple as saying "don't choke on unicode".
> Does the language this library is written in support that translation? Are there modules to do that? Is the license for those module(s) necessary compatible?
> Does the language this library is written in support that translation? Are there modules to do that? Is the license for those module(s) necessary compatible?
It's written in Python, which comes with support for pretty much every major encoding¹ out of the box, so yes.
There just isn't a lot of pervasive experience in the development community for multi-language unicode devlopment. Also xlrd is fairly old, although I don't know if that tool is part of what limits this to english.
Joel Spolsky said that ten years ago. The problem is that devs are afraid to learn unicode. They treat it like learning a foreign language. It's not even a fun problem, like learning a new programming language, so nobody makes time for it. The only people who learn it are those who make it a point of pride to implement something correctly and handle corner cases.
Unicode isn't even hard: Use UTF-8. Don't try to measure the length of a string unless you're rendering that string and measuring the length in screen units like pixels. If you do those two things, that's 90% of the effort of making Unicode-safe software.
I think both views are valid. Those who don't know how to write Unicode-safe software shouldn't feel shamed into learning Unicode before releasing open source work. Those who already know Unicode should feel happy that they're making other people's lives easier.
But these are file formats that may well not be encoded in UTF-8.. the formats already exist.. it isn't like he's creating a new spreadsheet format here. Some of them may well be encoded to something that works fine against unicode/utf-8, others not so much.
So you write FooToUTF8() and UTF8ToFoo(), where Foo is whatever the encoding is in the external format. Done.
As far as I know, UTF-8 will work 100% of the time, and is almost always the best internal representation for software you write due to how simple and uniform it is. If something is encoded in some other format, you can probably find a conversion function online.
Okay, so why don't you fork the project, and create your simple Foo/UTF8 methods, and confirm that they are the correct Foo/UTF8 methods for each of the document formats supported.
I'm not saying that it's really all that hard, but there are multiple document formats, and versions of those formats. The author obviously didn't need unicode support, so didn't test for it. I'm sure test cases, and a pull request would be welcome.
The grandparent probably wrote the comment in his spare time, too. Does that limit your entitlement to voice criticism or suggestions? Don't like it, don't read it.
It goes both ways. I hate developers that write some code, dump it on GitHub and say "It's open source, you can always fork it." Whatever happened to taking pride in your work and making it work the best it can?
Like other people have pointed out, handling unicode properly does not mean internationalization. Handling utf-8 isn't even difficult if you just keep it in mind.
I do take pride in my work, and every piece of software I write handles every use case I need it for explicitly. I take offense that you would imply otherwise knowing absolutely nothing of me and my craft. This isn't about UTF-8, it's about an illogical premise where some very shortsighted individuals would rather have only fully fleshed, fully baked products in open source. This is highly illogical, and would bury ideas potentially unexposed for others to coach and assist with. You aren't the judge of what others find difficult, but that doesn't mean that those that struggle with a concept cannot add tremendous value in other areas.
By the way, it's not utf-8, it's UTF-8. Whatever happened to taking pride in your writing and making it the best it can be?
Everyone has their own criteria for quality, and you can't hope to satisfy everyone. Everyone with even a mildly successful project in open source knows this. Scratch your own itch, make it work, accept any request that meets with your vision, and keep a permissive licence so those that don't can fork. Otherwise, the arrogance being asserted, that you can somehow determine if my contribution is worth of existing, is baffling.
I agree with you. Anything else just reeks of over-entitlement. I mean, if someone spends their free time to make something useful, that's great! If it doesn't quite meet your standards, that's your problem and you can either: fork it or send a pull request (ie fix it yourself), or pay someone (original author or someone else) to do it.
I'd rather people who build stuff for themselves release it to the rest of us than keep it to themselves.
It's one thing to internationalize software. That's hard. But not being able to handle UTF-8 in 21st century is downright shameful.
The notion of non-ASCII characters in user Excel documents IS NOT something rare even for English speaking nations. There are tons of people with foreign names, addresses and other personal information which is commonly stored in Excel documents. And the funny thing is: it's usually not alot of additional work to support UTF-8 if you START correctly.
Calling the work of someone who releases free software that they may have well hacked together in their free time downright shameful seems quite offensive and disregards the work they put into the project. Perhaps the OP had no need to use this code for non-English alphabets or is simply in the early stages and hasn't had the opportunity to fully test and implement this.
Regardless, I think people should be applauded for releasing their work instead of shamed. And of course, if it's not a lot of work, a pull request would likely be appreciated ;)
Hmm, I do not agree with you that the sole act of opensourcing a software should bring it above criticism. Any developer that takes a bit of pride in his work should at least keep himself to some minimal standards and I think supporting UTF-8 isn't an unreasonable baseline for software released right now.
> A Show HN needn't be complicated or look slick. HN users are comfortable with work that's at an early stage.
> Be respectful. Anyone sharing work is making a contribution, however modest.
> When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
I'm not saying it people shouldn't be open to criticism, but I think terms such as downright shameful fall under the category of gratuitously negative.
