Pinetab – 10.1″ Linux Tablet with Detached Backlit Keyboard - <AUTHOR> https://store.pine64.org/?product=pinetab-10-1-linux-tablet-with-detached-backlit-keyboard <comment><USER3> [https://archive.vn/Lm8EA](https://archive.vn/Lm8EA)

<comment><USER4> I get certificate invalid here..

<comment><USER5> Try:

[https://archive.today/Lm8EA](https://archive.today/Lm8EA)

[https://archive.is/Lm8EA](https://archive.is/Lm8EA)

[https://archive.fo/Lm8EA](https://archive.fo/Lm8EA)

[https://archive.li/Lm8EA](https://archive.li/Lm8EA)

[https://archive.vn/Lm8EA](https://archive.vn/Lm8EA)

[https://archive.md/Lm8EA](https://archive.md/Lm8EA)

[https://archive.ph/Lm8EA](https://archive.ph/Lm8EA)

One typically works.

List: [https://en.wikipedia.org/wiki/Archive.today](https://en.wikipedia.org/wiki/Archive.today)

Cloudflare is in a grudge match with archive.today:

[https://community.cloudflare.com/t/archive-is- error-1001/182...](https://community.cloudflare.com/t/archive-is- error-1001/18227)

<comment><USER6> All invalid certs/403, even google webcache is 404ing, how elusive...

</comment></comment></comment></comment><comment><USER7> Absolutely incredible for the $120 price point. If they release a PineTab Pro in the future with 4 (or dare I say 8GB) of ram, I'd be all over it. At that point, I could really start to be productive. 2GB is a bit limiting for the modern web unfortunately, but there is a ton of potential here. I'm considering buying one to use as my main machine for this next year at Uni. Taking notes in VS Code/Vim would be fine, but I could see some of my course load being hindered by the ram.

As a portable SSH machine, a kid's first computer, or a nice portable machine with a screen for hobby projects, I think this will be fantastic.

<comment><USER8> In case where the pine64 team is reading: +1

8GB RAM, 128GB MMC, USB-C for up to 300$ and it will be the perfect Microsoft Surface Go's contender I'm waiting for!

<comment><USER9> > 128GB MMC

Why MMC when there is NVMe?

<comment><USER10> eMMC should be cheaper. But I'm also prefer NVMe for computer.

</comment></comment></comment></comment><comment><USER11> I noticed this has a removable battery, which makes this very interesting to me.

What I'd like to know is if it will work with the battery compartment empty on AC power only.

I'd like to have "smart" displays wall mounted around the house with dashboards on them. I've read about so many instances where people used wall mounted iPads and Android tablets where the batteries would swell after a period of use.

<comment><USER12> > I've read about so many instances where people used wall mounted iPads and > Android tablets where the batteries would swell after a period of use.

Made that mistake myself. I now have a wall mounted iPad with the charger plugged into a timer powerpoint that only switches on for 1hr a day. Been running like that for 5+ years now without issue. (I'd planned for that to just be a proof of concept, and to use a wifi powerpoint that'd turn on when the battery dropped to 20% and back off where it hit 80%. The easy solution has turned out to be "good enough" and has remained in production, like that cronjob perl script from 2004...)

<comment><USER13> Really cool! Could you give specifics about the typical low and high of the battery cycle, please? (from XX% to XX%).

<comment><USER12> I'd been intending to aim for 20%-80% cycles, because I read that's "good for lithium batteries".

The timer switch I grabbed to do my proof of concept only has 15min resolution (it's a weird old mechanical one where you move plastic pins in the stop/start time rings). I recall setting it to 45mins because the docs says the iPad gets 80% charge in 1 hour, and it'd occasionally run down and switch off, so I bumped it up to 1hr and haven't touched it since.

I just checked now, it charged for an hour overnight finishing ~10.5 hours ago, and is currently saying 59% charge. I honestly have no idea how low or high the charge level gets, just that I haven't needed to wake it back up from a shutdown in over 4 years...

I've come to doubt the details there are important. Don't leave it on charge 24x7, that'll kill it fairly quickly (~9 months in one data point of mine). Charge it long enough and regularly enough to keep it running, but at the low end of that spectrum. Keep in mind my goal here is less "extend the life of the battery", and more " prevent the battery from swelling up and damaging the device/catching fire", but I suspect there's a fair bit of crossover between those goals, since I've not needed to increase the charge time in response to any battery capacity decrease over 5 years (which in retrospect surprises me somewhat).

If I was aiming to maintain the best possible range in an electric vehicle, I'd probably pay much more attention to max charge and min discharge levels, but "the simplest possible thing" has been working well enough for me to just leave it alone.

If it dies on me tomorrow, I'll be happy enough with the use I got out of it and the tradeoff of time I spent futzing with it.

(Note: I'm also quite familiar with abusing LiPo batteries way past safe limits, I raced FPV quadcopters 5-6 years back, and in my worst excesses, I'd be aiming to completely drain a flight pack in ~2 minutes. They'd end up too hot to touch, and start to decline to the point of not being race competitive within 20 or 25 cycles. They'd also catch into unextinguishable fire in big crashes and occasionally while charging. I have a healthy fear/respect of high capacity and high current LiPo batteries...)

<comment><USER14> I have a six year old phone that still runs on the original battery. The capacity is pretty low but still lasts for 2-3 hours of active usage. Just charge it for an hour per day and you'll be fine.

</comment></comment></comment></comment></comment><comment><USER15> Very interesting! I've been looking for cheap wall-mountable touchscreens so I can have permanent, single-purpose interfaces and displays. For example, I have a KanbanFlow board to track my work, and I use an old tablet mounted to the wall next to my standing desk.

I was thinking I'd get cheap Android tablets and root them, but I'd much rather support something where it's built for user control from the beginning.

<comment><USER16> Side thought... is it even cheaper if you just have displays/use an ESP to do http requests to a local server... guess depends what they have to do. I mean I think you would need a 32 to drive the display too vs. just an ESP01

<comment><USER17> I don't think they're capable of displaying a web page

<comment><USER16> Oh maybe I didn't read parent comment thoroughly enough I was talking about having a UI with defined buttons you click and it sends the http request.

Yeah missed the Kanban part

</comment></comment></comment></comment><comment><USER18> They are serious about not making profit with these. $100 for a full up tablet and it includes the keyboard/touchpad?

2GB of RAM is pretty limiting but 64GB of storage is quite respectable at this price point. The 6AH battery pack is quite beefy too.

<comment><USER19> "When fulfilling the purchase, please bear in mind that we are offering the PineTab at this price as a community service to PINE64 communities. If you think that a minor dissatisfaction, such as a dead pixel, will prompt you to file a PayPal dispute then please do not purchase the PineTab. Thank you."

no or low amounts of QA significantly reduce cost

<comment><USER20> With regards to dead pixels, every vendor I know of has terms like this, it's just hidden in the warranty small print, not on the store page:

[https://support.lenovo.com/ca/en/solutions/ht035306](https://support.lenovo.com/ca/en/solutions/ht035306)

[https://appleinsider.com/articles/10/11/05/leaked_apple_dead...](https://appleinsider.com/articles/10/11/05/leaked_apple_dead_pixel_policy_allows_two_for_ipad_none_fir_iphone)

<comment><USER21> I wonder what are the odds of finding dead pixels today. I saw lots of them in the past, and in a few cases they were really nasty to stand (imagine a pixel stuck at full brightness in the center of a screen mostly containing dark terminals) , but admittedly in the last 10 years or so I can't remember of a single one. However, although all vendors bury the dead pixel disclaimer, being so open about it makes one wonder if their quality checks are cheaper than others. I would happily pay more to be 100% sure there are no dead pixels btw.

<comment><USER20> Just a thought, it's a PITA, but you can do it yourself by buying one, if it has dead pixels resell it and buy a new one.

</comment></comment></comment></comment></comment><comment><USER22> The link (store page) is unresponsive.

The webpage for the product is [https://www.pine64.org/pinetab/](https://www.pine64.org/pinetab/)

<comment><USER23> It seems to be working now, just slowly.

</comment></comment><comment><USER24> How is touch screen on linux these days, I'm probably pick one up but can't imagine running UBports on 2GB ram.

I would rather use i3/lighter DE + touch screen support for some GUI apps?

<comment><USER25> Someone's set up a sort of dwm-based DE on the Pinephone:

[https://sr.ht/~mil/Sxmo/](https://sr.ht/~mil/Sxmo/)

<comment><USER26> [http://media.lrdu.org/sxmo_pinephone_demos/sxmo_demo_0_allfe...](http://media.lrdu.org/sxmo_pinephone_demos/sxmo_demo_0_allfeatures.mp4) (MP4)

...well that was... _interesting_...

</comment></comment></comment><comment><USER27> I like what Pine64 guys have been doing, great devices to hack at reasonable price creating foundation for a pure linux based linux mobile devices; of course projects like Ubuntu Touch, PureOS, PostmarketOS maturing at the right time has been a blessing.

Now, this is what I need Pine64 - 'A small pocketable, user repairable linux laptop with GSM module' which can replace smartphone. Current options are GPD[1], One-netbook[2] both of which are expensive, not-user repairable, built for windows.

Then there's planet computer's devices[3], but they seem to be android first although they offer linux as multi-boot option.

Why pocketable linux laptop when there's PinePhone, Librem5? Well, the main bottleneck in the linux app ecosystem is adapting it to the touch screen of the smartphone. I think a pocketable linux laptop could serve well in the interim, may be the form factor will prove better for productivity and will stay as a separate profitable segment.

[1][http://gpd.hk/](http://gpd.hk/)

[2][https://www.1netbook.com/](https://www.1netbook.com/)

[3][https://store.planetcom.co.uk/collections/devices](https://store.planetcom.co.uk/collections/devices)

</comment><comment><USER28> The Pine folks have been doing fantastic work over the last several years. Does anyone know of ways to support them other than buying products? I don't really need these gadgets right now, and don't have the time to tinker, but want to encourage the ecosystem from a long-term perspective. For example, I'd love to give them some money and become a long-term member/shareholder/something. I don't really care for the rate of return; I'm more interested in a reason to stay engaged with the organization as its products might mature into my use cases, and help them along the way.

<comment><USER29> One suggestion, buy a product for someone who could use it but doesn't have the resources. As a kid who loved to tinker and had no money this would have meant the world to me at that time.

<comment><USER30> Was thinking the same...school donations maybe?

<comment><USER31> Many libraries also have programs for children interested in tech, might be good to check with a local one.

</comment></comment></comment></comment><comment><USER32> This looks wonderful, and I bought it as soon as preorders opened; I'd love to have a Linux tablet to read books on and take to work (I'm a teacher, not a programmer). It definitely is pretty low-powered, though, and I'd appreciate a higher-end alternative. Is there _any_ Windows-based tablet that you can reliably and easily install Linux on?

<comment><USER33> >Is there any Windows-based tablet that you can reliably and easily install Linux on?

Samsung Series 7 Slate XE700T1A

<comment><USER34> Are there any tablets that have open drivers for GPU and touchscreen? Problem with blobs is that such tablets are forever stuck with ancient kernels.

<comment><USER33> The one I mentioned works fine with the upstream kernel for everything. It just has an Intel GPU.

<comment><USER34> Good to know, thanks!

</comment></comment></comment></comment></comment><comment><USER25> [https://www.youtube.com/watch?v=Ii6lAjgfW3c](https://www.youtube.com/watch?v=Ii6lAjgfW3c)

If this functionality was demoed by Apple on a new $999 "MacPad Pro" there would be arguments over if it was the end of the PC and the beginning of the next generation of computing, a leap like the smartphone revolution.

Edits: price, s/this/this functionality/

I took this out of context (sorry), it's a very pre-production device that has received a lot of work since then and will receive much more. [https://www.pine64.org/2020/05/15/may-update-pinetab-pre- ord...](https://www.pine64.org/2020/05/15/may-update-pinetab-pre-orders- pinephone-qi-charging-more/)

<comment><USER35> Are we watching the same video? This is basically no different to what you get on any Windows convertible (though the tablet-mode interactions are closer to the iPad), except way, way jankier.

<comment><USER36> Nah, that's _way_ higher latency than my Surface Book (which is a much more powerful machine, but is also driving a 3000×2000 display) gets. That video is at 25fps, and exhibits latencies of 7–8 frames (~300ms) on scrolling a web page, and 9–12 frames (~400ms) on resizing windows. I can't measure latency accurately on my device at present, but I estimate that I'm getting around 50ms of latency in both of those scenarios.

(Oh, I guess you were talking about the functionality, not the latency. Ah well, I'll leave this comment up anyway.)

</comment></comment></comment><comment><USER37> Does anyone know if there custom OS has a screen reader? I'm totally blind and this is priced at the point where I'd like to play with it assuming it's usable for me.

<comment><USER26> Wow, what an interesting question. Open source first-class accessible tinkerer/maker-oriented hardware design.

That gets me wondering... what would be the ideal here? I don't have much experience with blind-oriented usage but I get the impression blind users only keep screens around for when software/the OS falls apart and orientational cues completely break down... but perhaps sighted assistance is needed less often than I presume, and blind users simply use phones and laptops with screens because that's what dominates the market.

Maybe you could viably get away with having a quick-access mechanism that lets someone use their own device's display whenever assistance is required. I can totally see a device that serves VNC over HTML5 to any web browser via a built-in hotspot, that would be pretty universal.

Which leads me to the question of how useful touchscreen gestures are - <USER2> that's all touchscreens are useful for in a blind context - and if there isn't a better input method than that. I get the impression keyboards are pretty much "it". It would be pretty cool if your entire computer was a keyboard with a 3.5mm headphone jack :)

The Pinetab is basically a highish-end ARM system with its own bits of novel hardware added on, so the base question becomes "how usable is the mainline AArch64 Linux experience for blind users?". I suspect it's somewhere between "poor" and "fair"; and bespoke hardware in this device may add a small amount of extra strain on top of that.

Now I'm puzzling over which mechanical keyboards are the thinnest, and if you could cram a power bank and ARM development board into the footprint space underneath.

<comment><USER38> I've seen a computer in 2008 that was like the bottom part of a laptop and between the keyboard and where the hinges would be it had a 3 row braille display. It was pretty old at the time and quite thick, with modern technology could be as thin as a tablet.

These things have a very narrow audience so they're one digit more expensive than their regular counterparts.

</comment></comment></comment><comment><USER39> Just purchased one, very excited. Looking forward to it arriving sometime in August.

My use case is basic browsing, taking notes in meetings, reviewing papers (using something like xournal), SSH'ing into remote machines, a small amount of dev'ing (compiling on remote) and perhaps presentations (has HD output). I travel alot and having a machine that doesn't break my back would be cool. If the keyboard is half-way decent I may even use it for writing too.

The reason for this device over other existing solutions are many: low price, built for Linux, lightweight, low-power (good battery), form factor (where did you go netbooks :( ) and a great community!

</comment><comment><USER40> The further I get with computers the less I need. I've been teaching computer graphics using a 160 x 48 pixel display rendering Unicode Braille dots. It's absolutely enough for:

\- random colored text

\- line drawing fun

\- circles

\- z buffers

\- convex hulls

\- ray tracing spheres

(Checkerboards are too noisy though, and no Newell teapots. Alas, if only my browser supported PBM, the graphics format of winners.)

So yeah, bring it on! Doing more with less feels like a journey worth traveling. I want one!

<comment><USER41> May I know what's that 160 x 48 display and processor you are using to teach?

I am interested to learn low level stuff like CPU assembly, operating system and VGA, VBE, linear frame buffering graphics. I want to see how far I can go with low end x86, arm, misp, and fpga devices

</comment></comment><comment><USER42> I am not going to lie, I'm not a big fan of the arm experience on Linux. While the situation has improved, it is still a painful experience. It has always felt like you're trying to run windows 7 on a pentium II, regardless of lightweight desktop environments or even no desktop environment. That said, this does look like a very appealing solution for something to shove in the backpack when hiking or whatnot, as opposed to carrying around a 1.5k ultrabook. I'll keep an eye out and wait for some review and real-world experiences and I might jump on that train.

<comment><USER43> Isn't the issue just drivers?

</comment></comment><comment><USER44> I love what Pine is trying to do, but man those A53 CPUs and Mali-400 GPUs are really pretty crummy. Similarly spec'd Allwinner chips were on the PlayStation Classic and Nintendo Classic microconsoles.

<comment><USER45> Those were running emulators though, running native software will be more efficient.

<comment><USER44> The community has ported a bunch of native stuff and it still performs poorly.

</comment></comment></comment><comment><USER46> I have no idea what I'd do with one of these, but that price point is barely more than a Raspberry Pi 4 with a few accessories. I think I might buy one.

</comment><comment><USER47> Pricing Details:

The PineTab – $99.99 The magnetic backlit keyboard – $19.99

That's interesting. I love my iPad mini 5, but at this price I may have to pick one of these up.

<comment><USER48> Yeah for non iPad specific stuff ... just reading and streaming this might be way more cost effective.

</comment></comment><comment><USER36> I suppose the keyboard needs to be attached to operate?

I use a Surface Book. I've been interested to discover that I would quite often like to have the keyboard continue to work after detaching the base, because when drawing on the device a keyboard is still useful for switching between tools, activating things, typing in precise values when necessary, _& c._ To be sure, a large part of this is just that I'm using apps that haven't been optimised for keyboardless usage (I'm talking things like Krita, Inkscape, OpenToonz), but even if they were, a keyboard would still be useful. As it stands, I'd need to buy a second keyboard, one that worked by Bluetooth, to achieve this goal.

(In the particular case of the Surface Book, detaching the base isn't _quite_ as useful as you might imagine, because ¾ of the battery life is in it, so you'll get ~3h at most, <2h if using it much.)

<comment><USER49> It's got pogo pins, it looks likely to just be a pogo pin USB port down there? Pretty sure they'd mention if the keyboard was wireless. Honestly, I hate having a second battery to worry about charging: I'd much rather a keyboard just be a keyboard.

</comment></comment><comment><USER50> The CPU vendor apparently distributes binaries for this SoC that infringe on u-boot and linux's licenses: [https://linux- sunxi.org/A64#GPL_Violations](https://linux-sunxi.org/A64#GPL_Violations)

Do you know if these binaries are required to run the Pinetab?

<comment><USER51> No.

</comment></comment><comment><USER49> I bought one. The USB configuration sounds a bit sad. USB 2.0 Type-A and Micro-B is a very dated configuration, especially considering the PinePhone has a USB-C. But I am interested in seeing how the ecosystem comes together and the price is absolutely right for this thing.

</comment><comment><USER52> If this had USB-C for charging I'd be really interested and would purchase. I can live with the rest of the specs.

I know USB-C has a bad rep but it is honestly just amazing having one charger that does everything. I don't want to regress from that

</comment><comment><USER53> I've been waiting for this to come out. Unfortunately, I tried to buy the pinetime late last year and discovered they only sell through paypal and you need an account to make the payment, you can't just pay by credit card.

If there's anyone from pine watching: Please, add a normal credit card option. Paypal is a horrid company. I'm prepared to pay directly with a credit card via them, but I _will not_ make an account with them just to buy your stuff. Please let me give you money without making a legal agreement with a third party :(

<comment><USER54> You don't need a paypal account to pay by credit card via paypal. Select "Pay by Debit or Credit Card" when it asks you to login to paypal.

<comment><USER53> That option is enabled or disabled by the user.

Pine has (still) not enabled it:

[https://i.imgur.com/Y1OhCkX.png](https://i.imgur.com/Y1OhCkX.png)

In case anyone from pine is watching, here's the doc on how to do it:

[https://developer.paypal.com/docs/integration/direct/payment...](https://developer.paypal.com/docs/integration/direct/payments/guest- payments/)

It's like....5 clicks.

<comment><USER54> Interesting, it's enabled for me -- that's how I bought it -- without creating an account. Maybe this feature is perhaps region locked somehow? I'm in UK.

EDIT: it is indeed gated by some vague heuristics[1].

>Buyers don't always have the option to complete their purchases without using or creating a PayPal account. This option is presented based on several risk factors, including but not limited to the buyer's PayPal purchase history, PayPal cookies stored on the buyer's computer, the buyer's location, or a credit assessment.

[1] [https://www.paypal.com/uk/smarthelp/article/how-do-i- accept-...](https://www.paypal.com/uk/smarthelp/article/how-do-i-accept- credit-cards-with-express-checkout-using-the-guest-checkout-option-ts1623)

<comment><USER53> >PayPal cookies stored on the buyer's computer

That's probably why. I use addons that autodelete cookies as soon as I leave webpages because no one has the luxury of pretending they don't know how badly cookies are abused at this point.

I guess the inevitable next step was for companies that abuse cookies to start punishing people for refusing to take their shit.

I reiterate: paypal is a shit company. Pine, please provide an alternative.

</comment></comment></comment></comment></comment><comment><USER55> It would be even greater with some quick accessible GPIO pins.

That would make this tablet the ultimate Pocket CHIP[1].

[1] [https://en.wikipedia.org/wiki/CHIP_(computer)#Pocket_CHIP_an...](https://en.wikipedia.org/wiki/CHIP_\(computer\)#Pocket_CHIP_and_Pockulus)

</comment><comment><USER56> I've got an old windows tablet with similar specs, old intel atom, 2GB ram. (linx1010b)

Its gathering dust because its so underpowered, could not find a use for it as a GUI user device.

I think some kind of kiosk / iot hub with display application could work, if you put in the effort.

<comment><USER57> Newer Linux releases generally work quite well on these tablets as far as hardware support goes. The one thing that's marginally underpowered is the amount of RAM, and in my experience 2GB still suffices for simple use cases.

</comment></comment><comment><USER58> ...2GB RAM is a bit of a disappointment for those of us spoiled by higher end devices (like my Note 10+ w/ Dex), BUT - there is room to expand with some kinda SD and then map a bunch of SWAP space to it, right?

Won't a generous allocation of swap compensate?

<comment><USER26> As someone who has more experience than I care to quantify regarding RAM- starved, swap-abundant systems: no. Well... OK, a subjective measurement on the "death by how many thousand cuts"-scale would be somewhere between 10,000 and 1,000,000 cuts, IMO, depending on what you're trying to do.

You'll also rapidly exhaust the SD card's flash lifetime, and all the spare capacity... which will make the SD return read errors, nicely corrupting the contents of RAM.

You can verify the slowdown/lag/pain factor easily enough: boot Linux on any PC with `mem=2G`, attach an SD card you don't mind nuking :), and go nuts.

</comment></comment><comment><USER59> Cortex-A53 is a _very_ slow _in-order_ core. Think Pentium 1 -level IPC. Eg: it can dispatch at most one multiplication, and will stall the entire pipeline for a few cycles if you try another one soon after. I doubt this is going to perform well

<comment><USER60> OTOH, no speculative execution side channels.

</comment></comment><comment><USER61> This may finally replace my surface-rt for movies on long car-trips; it's a 16:10 rather than 16:9 but otherwise checks all the boxes: widescreen, usb port (so I can just put files on an old thumb drive), and can run VLC.

</comment><comment><USER62> This is interesting to me because I'm in the market for a new tablet.

Is this more of a hacker device (IR blaster, odd assortment of ports, full OS, etc.) or consumer? It should ideally pass the wife test...

<comment><USER49> Not a ton of ports, USB 2.0 Type-A and Micro-B, Micro-HDMI out, SD card. But there's an expansion card slot, which is pretty unheard of for a tablet. So you can add like an SSD or a LoRa radio or what-have-you.

</comment></comment><comment><USER63> I kinda feel like the screen lets it down a bit. Much of this appeals (M.2!), but I can't see myself ever buying a 720p device again.

</comment><comment><USER64> So they wrapped some clam-shell around their SOPINE A64 COMPUTE MODULE?

[1] [https://store.pine64.org/?product=sopine-a64](https://store.pine64.org/?product=sopine-a64)

[2] [https://wiki.pine64.org/index.php?title=PINE_A64-LTS/SOPine](https://wiki.pine64.org/index.php?title=PINE_A64-LTS/SOPine)

Looks like _Resterampe_ /left-over sale to me.

Come on, 2GB? In 2020?

</comment><comment><USER65> Noob question: please tell me that it's simple to remap the keyboard so that it matches, say, a Swedish keyboard layout?

<comment><USER66> You just change some config file and that's it.

</comment></comment><comment><USER67> Meanwhile coming up on a month of waiting for my ubports pinephone to arrive... Not even a shipping update yet.

<comment><USER68> Uhhh yeah they have [https://forum.pine64.org/showthread.php?tid=9942](https://forum.pine64.org/showthread.php?tid=9942)

<comment><USER67> I purchased directly from their web store, not via a forum group buy or other means. They have my contact information, and I have not received a single peep to inform me on the status of my purchase. Just radio silence.

If I'm expected to go root out some forum thread to monitor progress on things I purchase from the pine64 store, that's worth noting here to inform everyone's expectations.

<comment><USER68> You said they didn't give a shipping update. They did. Doesn't matter if you don't like they way that they did so.

<comment><USER67> They didn't give _me_ a shipping update.

They could post a shipping update on the wall of their local laundromat for all the good that did me when I'm not monitoring their message forums.

If not for this thread, I'd still be operating in the dark having basically forgotten I even bought the thing. I appreciate your comment pointing me at the forum, pine64 should have emailed that link to everyone who ordered one in the affected time period.

</comment></comment></comment></comment></comment><comment><USER69> Wow, Pine64 has a really beautiful logo.

</comment><comment> awinter-py would love to know what the model is that lets these penetrate the mass market

I buy mine because I'll jump through any hoop to not carry around a fortune 500 in my pocket

For the consumer market -- runnability of android? hardware quality? low price? Some compatibility factor that only an open company can hit?

</comment><comment><USER70> Took me quite a while, but I finally got my order in.

It'll come, eventually, I hope.

</comment><comment><USER71> I'm thinking a portable SDR setup

</comment><comment><USER72> Does it run vscode?

<comment><USER73> Does it run emacs?

</comment></comment><comment><USER74> 2GB ram seems to be pretty limiting.

</comment><comment><USER75> I'd rather get second hand iPad.

<comment> yjftsjthsd-h An iPad can't do things that this does; in particular, any pine product gives you full control the device and the ability to execute arbitrary code.

</comment></comment><comment> Maha-pudma Is that a 30 day warranty? No thanks.

<comment><USER76> Most failures either happen shortly because something was made poorly or after >1 year which is why extended warranties are mostly garbage.

Just for the sake of argument lets suppose it had a 1% chance of failing between 30 days and 1 year even though I would hope it is far less when it would normally have been covered. Assume you remedy the issue by replacing it out of pocket.

Expected cost is 0.99 * 100 + 0.01 * 200 = $101

Also keep in mind that brands pay for warranty services out of profits earned from higher margin sectors and volume neither of which is applicable here.

<comment> Maha-pudma I didn't expect my comment to be popular, and it's probably going to decimate the measley 7 points I've accrued (I had 9 prior) as might this one, but I tend not to buy anything without a decent warranty. I'm certainly not buying anything that could go wrong after 30 days without any recourse other than paying to get it fixed or to buy a new one. My view about warranties are to do with the confidence the seller/manufacturer has in their product, this one doesn't endear my confidence in the product. Just my opinion but I keep holo of my electronics as long as I can. Still using a phone bought 4 years ago, laptop 8 years ago and a desktop I built 10 years ago.

<comment><USER76> Complaining about down votes usually attracts you guessed it... more down votes.

I didn't down vote either your prior post or this one. I value durable things. My 8ish year old desktop just died. Both my phone and my laptop are 5 years old. On the other hand I see the value in cheap things that will be affordable to all made by small distributors that value our freedom to use our devices. Everything in life is some degree of trade off and I see room for this one.

<comment> Maha-pudma Im not complaining, I'm expecting it; and I'm not fussed either, I don't care about internet points. Down vote away it bothers me not.

</comment></comment></comment></comment></comment><comment><USER77> Wow, I was ready to pull the trigger on this until I saw the $30 shipping.

<comment><USER49> They don't subsidize anything here, so yeah, cost of shipping is really the cost to take a box from China to your house, pretty much. FWIW, when I got my PineBook Pro, DHL was literally like overnight from Hong Kong to the US. I think if you consider it part of the cost ($150 for tablet and keyboard shipped), it's still a pretty good deal.

<comment><USER77> Yeah, good point. Maybe I am just conditioned to subsidized free shipping from China.

<comment><USER78> That's going to end. The UPU agreed to let the US charge 70% of its domestic shipping cost to foreign carriers.</comment></comment></comment></comment>


Box.net Raises $50 Million From Salesforce And Others - <AUTHOR> http://techcrunch.com/2011/09/28/cloud-storage-platform-box-net-raises-50-million-from-salesforce-and-others/

<comment><USER2> I'm still trying to wrap my mind around what makes Box so special. Is there anything behind it that a hand full of us couldn't replicate on the amazon cloud in an afternoon with a couple laptops and a pot of coffee?

Plus, isn't the file sharing market going to be shrinking as more of these documents are going to be created and collaborated on in an application native to the web?

And the Google Drive stuff that got leaked?

Salesforce/Marc have made some good investments with Heroku, Mashery, and a list of others but I'm not so sure how long box can keep this up. I know they're hiring aggressively though.</comment>


NASA launching spacecraft to explore beyond our solar system - <AUTHOR> https://www.facebook.com/NASA/videos/10156185319831772/ <comment><AUTHOR> NASA launching a planet researching spacecraft to search for worlds beyond our solar system that orbit other stars. The exoplanet survey satellite is called "TESS". It shall scan nearly the entire sky to discover planets around the closest and brightest stars.</comment>


Grokking Python 3's str - <AUTHOR> https://sircmpwn.github.io/2017/01/13/The-problem-with-Python-3.html <comment><USER3> Python 3 has arguably one of the best built-in string implementations around.

In Python 2, "unicode" was a type whose codepoint width depended on the interpreter build - 2 bytes on "narrow" builds and 4 bytes on "wide" builds. Since most builds were "narrow", in practice non-BMP codepoints were a real challenge to use.

Furthermore, most languages with a "wide" string type use a fixed 2 bytes per codepoint (Java, C#, C++, ...), which wastes space when you're dealing with ASCII a lot, and is a pain to work with if you have non-BMP codepoints, since now indexing requires scanning the string from start to end.

In Python 3, with PEP 393, strings now have a flexible internal representation which can use 1, 2, or 4 bytes per codepoint depending on the largest codepoint in the string. This saves both space and processing time (in most common situations) since common string operations like indexing and slicing are constant time. This representation also allows it to scale from ASCII to astral codepoints with ease.

Python 3 is worth the switch. Correct, strict separation of 'bytes' (bucket of octets) and 'str' (sequence of codepoints) is really the only way to preserve sanity and interoperability with today's encoding-rife reality.

<comment><USER4> I'm not disagreeing but the situation is a bit more complex. For example ISO 10646 ("Unicode") has multi-code point sequences denoting still a single character (such as variation sequences, which are actually used in standard HTML entities).

Moreover, there are languages/scripts challenging the notion that a particular byte-unit corresponds to a single character.

Treating strings as byte sequences (with optional UTF-8 interpretation/checking, uppercase/lowercase conversion if the concept even applies, trim functions based on all Unicode spaces not just those characters in US-ASCII etc.) is entirely a defensible choice for a programming language.

<comment><USER5> > For example ISO 10646 ("Unicode") has multi-code point sequences denoting > still a single character

I only know two programming languages that deal correctly with that: Swift and Perl 6. If you know more, please tell me.

<comment><USER6> Rust separates this out; the standard library gives you bytes and Unicode Scalar Values. Grapheme cluster stuff is in a package on Cargo, maintained by the Servo team.

<comment><USER7> You can iterate over Grapheme clusters using the standard library: [https://doc.rust- lang.org/1.3.0/std/str/struct.Graphemes.htm...](https://doc.rust- lang.org/1.3.0/std/str/struct.Graphemes.html)

<comment><USER6> Those are unstable docs for 1.3; they don't exist in today's Rust.

</comment></comment></comment></comment></comment></comment><comment><USER8> The fact that Python 2 is so permissive when mixing bytes and strings I think is the fundamental reason why people think Python 3 strings are broken.

In practice what happens is that Python 3 won't allow you to mix bytes and strings at all, and it will force you decode and encode properly. Python 2 will happily try to implicitly convert to and from ascii when needed. Now, this might seem simpler at the beginning because in Python 2 you require less boilerplate code, but then later, when you have to deal with a different encoding or when you use non ascii characters, you get really weird, hard to debug problems that cause real pain. Python 3's strictness is helping you preventing these kind of cases.

<comment><USER9> Taking away permissiveness from a programming language just leads to developers not upgrade. No surprises there.

Yes, Python 3's stricter model is less error prone (vs python 2 u').

the more annoying thing for me personally is the "print" function rather than previous "print" statement... Bugs the hell out of me.

<comment><USER10> I hear this complaint about print all the time but I have never understood it. Why is print so special that it needs dedicated synta? Most languages don't do this and people don't seem to mind. Also, I almost never physically type print, but I do type a lot of function calls, so if anything I am more accustomed to typing it as a call.

<comment><USER11> The print statement is a little more convenient in the REPL. Otherwise there is little to complain about having a more consistent, extensible print without any magic. Every Py2 coder should be sticking in "from __future__ import print_function" to train themselves for the transition.

<comment><USER12> > The print statement is a little more convenient in the REPL.

IIRC ipython has a feature where you can prepend slash to any function (at the beginning of a line) to have parens inserted automatically, ie.

        In [0]: /print "foo"

is executed as print("foo"). There - problem solved, and for all functions, not just one special case.

Honestly, the crazy `print >>fileobject, "foo"` syntax is enough of a reason for removing it (print statement) from the language. It was unpythonic and I'm surprised it lasted this long in the language.

<comment><USER13> Yes, I don't like that last usage too. Non-orthogonal syntax is slightly harder to learn / remember, and the more of if there is, the more the cognitive / memory load. Of course, no language can be perfectly orthogonal or regular, though I guess Lisp comes close. (Not an expert on language design or theory.)

</comment></comment></comment></comment></comment></comment><comment><USER14> Last month, we had to add support for HINDI language in our APIs within 2 weeks as Indian govt wanted to launch learning program in both languages. We being a young startup of less than 2 years could not afford to lose this opportunity by asking more time. Because all of our code was in python3.5, there was nothing we had to do. Hindi support was magically available and everything worked flawlessly.

Fingers crossed on the program launch... :)

<comment><USER13> What sort of APIs and learning program, if not confidential?

<comment><USER14> Its a learning program for budding entrepreneurs. We are at www.upgrad.com There are APIs for question, answers, feedbacks, discussion forum etc

<comment><USER13> Sounds interesting, thanks.

</comment></comment></comment></comment><comment><USER15> It may be true that one of the issues with Python 3 strings is people not grokking them, thus littering their code with useless/redundant/wrong `.decode()` and `.encode()` calls. But I say this is a problem with Python 3 _itself_ , since it obviously just replaced one set of problems with another.

I think the fundamental mistake of Python 3's approach to strings is assuming that programmers mostly meant "string" when they used strings in the past. This may be true in web circles, but in most other areas of application they actually meant (opaque) bytes. (`from __future__ import unicode_literals` makes more sense in this scenario, and I've been using it since forever.)

It's the changing of default behavior that confuses people!

Also, the standard library has a few places where the maintainers don't seem to grok strings either. Take the "json" module for example: Why does `json.dumps()` return an "str" and `json.loads()` doesn't accept "bytes" as input? (Hint: JSON is, by definition, UTF-8 encoded, so "dumps" should return "bytes" and "loads" should accept both.)

(I should mention that my native tongue uses characters outside of ASCII, so I it would seem that I should be asking for unicode everywhere.)

<comment><USER16> JSON is a text format, not binary [http://www.ecma- international.org/publications/files/ECMA-ST...](http://www.ecma- international.org/publications/files/ECMA-ST/ECMA-404.pdf)

JSON text is a sequence of Unicode code points, not bytes. Python 3 str type is ideal to represent JSON text.

On the internet "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32" [https://tools.ietf.org/html/rfc7159](https://tools.ietf.org/html/rfc7159)

json.loads() accepts binary input on Python 3.6. using the encoding detection scheme from the obsolete rfc 4627 that relies on now false assumptions (that json text represents either array or object).

</comment></comment><comment><USER17> In Python 3, a "bytes" type is too much like a string. It's supposed to be an array of [0..255]. But

        >>> s = bytes([97,98,99]) # created an array of "bytes" from a list of ints.
        >>> type(s)
        <class 'bytes'>   # it's really a type "bytes"
        >>> s
        b'abc'            # but it prints as a string
        >>> s[1]          # each element, however, prints as an integer
        98

Python 3 thus isn't rigorous about "bytes" as an array of byte values. It's become less rigorous; you can now use regular expressions on "bytes" types. If Python 3 had taken a harder line, that "bytes" is just an array of bytes, the distinction would be clearer.

Actually, Unicode has worked fine in Python since Python 2.6. You just had to write "unicode" and "u'foo'" a lot. In an exercise of sheer obnoxiousness, those were originally disallowed in Python 3, instead of making them null operations.

Strings in Python 3 appear to be arrays of Unicode characters. This is a bit tricky, because Python doesn't have a Unicode character type. Elements of a string are also strings. There's no type like Go's "rune".

Python has successfully hidden the internal structure of UTF-8 strings. Internally, representations can be 1-byte, 2-byte, or 4-byte, plus an optional UTF-8 representation. This means a lot of run-time machinery.

Go and Rust both have a string type that is both internally and visibly UTF-8. They're subscriptable, but at the byte level. An element of a Go or Rust string is not a string, a character, or a rune - it's just a byte out of the middle of something. The same is true for slices of strings; they are not necessarily valid UTF-8. This is a cause of trouble. You shouldn't be subscripting through UTF-8 byte by byte. In practice, you have to be aware of the UTF-8 representation in Go and Rust, or use a library which is. Here's my grapheme-aware word wrap in Rust.[1] Too much touchy fooling around with byte- level indices into arrays there.

Arguably, if you're going to use UTF-8 as an string representation, subscripts should be of an opaque type, not integers. You should be able to move forward or backwards one grapheme at a time cheaply, and if necessary, create an array of slices which represent all the graphemes in the array. Then programmers could random-address strings without fear, and you don't have multiple internal representations.

[1] [https://github.com/John-Nagle/rust- rssclient/blob/master/src...](https://github.com/John-Nagle/rust- rssclient/blob/master/src/wordwrap.rs)

</comment><comment><USER18> Perhaps the problem with Python3's str type is that a string type shouldn't be challenging to grok?

Also, for those of us who learned computer science back before UTF-16 was a standard, a "string" has always meant an array of chars, and a char was a byte. In some languages this is still the case.

In other languages, from Pascal to Java and beyond, a string has been a distinct class or type. Though generally those types began as a hint abstraction around an array of bytes. Surprise, surprise, that's how Python2 has always done it.

So Python3 changed which internals it uses for its default string type (pro tip: a b'foo' object in Python2.7 or Python3 isn't "a bytes", it's "a bytestring".)

I happen to think that this is a good choice in Python3. It's not 1996 any more. People expect software to support accented characters and ridiculous emoji. Default Unicode strings are easier to work with for most purposes that involve accepting text from a user and returning text for a user. For most of us it's worth the additional disk space and memory trade-offs even for things like dict keys that don't benefit from Unicode.

People whose work involves processing binary sequences as bytes for convenience are now inconvenienced and understandably frustrated, but they're not the majority of users of the language.

The author is correct that people who expect Python3 strings to be arrays of bytes are mistaken. But the author is wrong to tell people that what they've worked with as a "string" and considered a "string type" all their lives -- and which is STILL considered a "string" in many languages is not a string at all. It's still a string. It's still a type of string. Even Python still calls it a byteSTRING. It's just no longer the way Python internally represents a sequence of characters surrounded by unadorned quote marks.

<comment><USER19> _(pro tip: a b 'foo' object in Python2.7 or Python3 isn't "a bytes", it's "a bytestring".)_

Quotes from the Python 3 documentation:

 _Bytes literals are always prefixed with 'b' or 'B'; they produce an instance of the bytes type instead of the str type._

 _class bytes([source[, encoding[, errors]]])_

 _Return a new "bytes" object, which is an immutable sequence of integers in the range 0 <= x < 256\. bytes is an immutable version of bytearray – it has the same non-mutating methods and the same indexing and slicing behavior._

[https://docs.python.org/3/library/functions.html#bytes](https://docs.python.org/3/library/functions.html#bytes)

[https://docs.python.org/3/reference/lexical_analysis.html#st...](https://docs.python.org/3/reference/lexical_analysis.html#strings)

<comment><USER16> "bytes" is the type for bytestrings on both Python 2 and 3.

</comment></comment></comment><comment><USER20> Gah. No.

Unicode code points (which is what a str is a sequence of) are not characters. That is not a one-to-one mapping, nor a one-to-many mapping. That is a one-or- many-or-none to one-or-many "mapping". And glyphs are a third category that we aren't even getting into.

<comment><USER21> Well, we are slowly approaching the "truth" .-)

Frankly I think most people don't care about the complexities of Unicode. Count me in. I treat it as a necessary evil. What I do with it is mostly concerned with the characters (code points if you insist) from the ASCII range that are in there (for example, splitting lines or words). I hope it's okay to ignore code points vs glyphs etc. in this case?

<comment><USER21> Btw. I'm fully aware that this is just the bytes vs unicode issue, taken to the next level.

The difference however is that a) most data doesn't contain combining code points while much data is non-ASCII unicode, and b) software (i.e. most software, with the exception of perl 6 and probably few others) doesn't have convenient support for glyph-level strings yet -- I wouldn't mind if it had.

</comment></comment></comment><comment><USER22> Latin-1 files work just fine. The examples in the post are just overly complicated: open('test.txt','w',encoding='latin-1').write('No need to separately encode or decode.')

<comment><USER23> Yours is the correct way of doing it, but I chose to do it this way because I felt that this example gives more insight into the concepts this article is trying to explain.

</comment></comment><comment><USER24> The way I grok the computer science, strings are sequences of zero or more characters input into automata and unicode is a way of encoding text. Text is a sequence of one or more glyphs input into humans. Thus, for me, the implementation of String in Python 2 is about as sound from a computer science perspective as an implementation can get. By which I mean that in the end all data boils down to bits and clustering the bits as bytes is about as reasonable as alternatives. On the other hand, Python 3 treats strings as text and this necessitates all the overhead of multiple encodings and converting glyphs from one language to another language according to the messy and inconsistent and incomplete rules of human language. For me, it would have been better if Python 3 (and most other languages) had a 'Text' type in addition to the String type.

The problem is sloppy use of language in a domain where usually it is ok but sometimes it isn't.

<comment><USER25> Treating strings as "a sequence of bytes" is perfectly fine if you never, ever interpret or manipulate the contents.

As soon as you want to e.g. limit to 160 characters and suffix with an ellipsis, you run into problems of "what is a character", and you can't even call it a single unicode codepoint. Is "Z̴̛̺͉͙͚̰̔̏ͧͅ" is a single character, or over 10? Can you even call it a single "glyph" since it's formed of many units? Here's the unicode representation:

        Z\u0314\u030F\u0367\u0334\u031B\u033A\u0349\u0359\u035A\u0330\u0345

Which is a whopping 46 bytes in UTF-8. Or what about unicode flags and their 2-character representation: [https://esham.io/2014/06/unicode- flags](https://esham.io/2014/06/unicode-flags)

Strings as a concept as they currently stand are absolute nonsense. A "Text" type might resolve the semantic problems (and I love the name, this is a great idea), but strings _are_ text. Any other use is just abusing the container because it's easier to type "v1.2.3" than to make a "Version(1,2,3)" structure (especially when you have to communicate it across different programs / languages).

<comment><USER24> To me, because texts get encoded into strings (or strings encode texts) they are not the same thing. For example, Base 64 encodes data into a string, but the source is not necessarily a text. That's a separate issue from the way 'string' often gets used in the context of programming...a context in which even the otherwise pedantic seem to lose the faith ('regular expressions' is another one that is closely related).

Whether or not Z̴̛̺͉͙͚̰̔̏ͧͅ is a character (in terms of computer science) is a matter of whether or not it is part of the input language which some machine accepts. Which is to say it is no different than whether or not 'HashMap' is part of the input language to a compiler (yes for Java, no for Python).

<comment><USER25> Base64 is a text representation of a binary blob of data - it's just a protocol that happens to limit itself to a less-likely-to-be-mangled-by-bad- string-handling-code sequence of bytes.

Regexes are a great example - they're text that is parsed into a parsing- engine that can be executed. The text part is just a human-interface protocol over many possible implementations, and importantly, it has a standard. Slightly-varying standards at times, but everything trends towards Perl's version, plus/minus some features. And yes - implementations can choose which variant(s) they support, because they control its interpretation.

Programming languages don't have a choice about if "Z̴̛̺͉͙͚̰̔̏ͧͅ" is a character though, if they deal with human-language input and output. Humans have already decided. When it's displayed, it either is or is not, often based on the viewer's language (e.g. `str.lower()` is locale-sensitive, but many programming languages ignore this and only deal with ASCII for English speakers). If the program doesn't understand how it's dealing with this human <-> computer protocol and mangles it, it's just as bad as something that mangles other protocols like TCP/IP, except that humans are _occasionally_ more forgiving.

\---

edit: I should probably tl;dr this.

There is a right way and a wrong way to manipulate human-language text. And it's _extremely_ complicated to do correctly - people are difficult. Shoving it under the rug and ignoring it entirely, as has been done by most people in most languages, is 100% the wrong "solution".

Python 3 (or even better, Swift) have taken a step in the right direction to reduce accidents - it's painful because it requires correcting long-standing horrifically-wrong habits.

<comment><USER24> I used the term 'regular expressions.' I did not use the term 'regexes'. Regular expressions are clearly defined and have mathematical properties including equivalence to (or the ability to unequivocally and fully describe) finite automata. Conversely, regexes are not clearly defined mathematically.

There's nothing wrong with imprecision when precision is not called for and particularly when the imprecision facilitates communication. Sometimes however the abstractions leak and expecting the string type to embody the properties of human text is one of those...at least in my opinion. Other people may have different opinions.

<comment><USER25> Ah, yeah, you're entirely right about the regexes. My mistake.

So I think we mostly agree. My question is then: what _are_ strings for, if not Text? It makes a terrible enum, a weirdly-limited escape-hatch for ignoring type systems, and an immensely wasteful protocol.

</comment></comment></comment></comment></comment></comment><comment><USER26> It's true that programmers don't understand Python3 strings. But the language is to blame for being opaque.

Go is right up front: Go strings use UTF-8 and Go source code is in UTF-8. You can get the length of a string in bytes, or in runes. There's only one string type. Since every programmer needs to understand UTF-8 anyway, you can understand it immediately.

I tried to find how Python3 unicode strings work, but I could not find it anywhere, until I saw nneonneo's comment here.

</comment><comment><USER27> Interesting, I haven't ever read about anyone thinking Python 3 is the one that has broken strings. It's always been the Python 2.

<comment><USER28> Zed Shaw, author of _Learn Python the Hard Way_ , thinks Python 3 strings are broken. He also needs to read this article.

[https://learnpythonthehardway.org/book/nopython3.html](https://learnpythonthehardway.org/book/nopython3.html)

</comment></comment><comment><USER29> I'm doing ML in Python 2 and I can't see a single reason to move to Python 3. Every article is about strings, but in fact I needed to work with Unicode once (mostly doing computer vision tasks, but once trained a RNN on a book in my native language just for fun) - and I don't remember ANY problem with it in Python 2.

So, why should I bother migrating? I moved to C# 7 instantly and never looked back, for example, because it has tons of stuff. But the only thing I hear about Python 3 is "it's so much better!!!111" and "strings, you need it".

<comment><USER30> If you are not using strings then very few things are different between Python 3 and 2 so the cost of change to a more maintained interpreter is even smaller for you. The only real problem you might have is having some library that doesn't have Python 3 support. Also since you are dealing with ml I must warn you that the developers already committed to not support Python 2 in the future, not sure about numpy though.

<comment><USER31> Python 3 has mostly more stuff than Python 2 in the stdlib, some Syntax improvements, most of which are supported by Python 2.7 backports as well. So yes, arguably there are entire classes of problems were one doesn't need to care about differences between Python 2 and 3. But there are also many classes of problems where the differences matter very much.

</comment></comment></comment><comment><USER32> I agree with the article that Python 3 has great character string handling, but I'd suggest that the author does not understand why people like Python 2's system.

Proper handling of unicode glyphs makes for a great demo and is clearly the proper behavior, but does not represent a common use scenario.

It's fairly rare to be doing sub-string manipulation of user input or strings that will be displayed. Instead, it's much more common to be transporting data around inside strings. Maybe you're moving some JSON, or some binary data or csv content. In this examples, you're moving data from one point to another and the Python 2 approach is far simpler. What encoding is it? Is it unicode? For most applications, it does not matter. You can put the data in a str, then pass that str to a function.

In Python 3, this scenario gets more complicated. Is your data in bytes? Is it in a str? If it's in a str, how is it encoded? The Python typing system does not make finding these things out smooth. The details will determine which functions you can pass the data to and what transformations you (may) need to perform. Python 3 makes the programmer work harder to pass properly-tagged string data to functions, which generally makes string handling code more finicky and complex. The result is a string system that is _much_ more predictable and understandable in the failure case, but is more verbose in getting there.

It doesn't help that Python's poor type management tools mean that your first indication you mis-handled a string in Python 3 is the same as Python 2 - unexpected output to a buffer (often b'string' instead of terminal-killing garbage).

<comment><USER23> You shouldn't be moving things like that around in strings. You should be moving them around as bytes, then decoding them when you need to manipulate them. Your strategy is probably going to lead to subtly broken behaviors in your program. The problem here is not how Python 3 handles strings, it's how you're handling strings.

>It doesn't help that Python's poor type management tools mean that your first indication you mis-handled a string in Python 3 is the same as Python 2 - unexpected output to a buffer (often b'string' instead of terminal-killing garbage).

I agree, Python's behavior around implicit conversion of things to str is pretty bad. It would be better to throw a TypeError.

<comment><USER32> This is exactly what I mean.

I know I should move binary data around as bytes. I'm not saying I want to (or intend to) move binary data around as strings.

I'm saying that, in Python 2, you get a str - which happens to be binary and you don't have to worry about it. Even if it's unicode, it'll still work - <USER2> just won't matter. In Python 3, it depends on what the library gives you. Did it give you bytes? Maybe a str? You'll need to check and do the proper conversion to bytes. The behavior that Python 3 forces on you is safer and more correct, but it's behavior that you did not have to go through in Python 2.

Sometimes, in Python 3, the library gives you bytes and you want bytes and you're fine, but it's common that you are not.

</comment></comment></comment><comment><USER33> Couldn't agree more with the article or the conclusion: "python 2 is dead. Long live python 3"

</comment><comment><USER34> With these examples, I finally understood the difference between Python 2 and Python 3.

</comment><comment><USER35> What does "to grok a string" mean? It is used across the article and comments, yet is not immediately referenced in Google.

<comment><USER36> [https://www.merriam-webster.com/dictionary/grok](https://www.merriam- webster.com/dictionary/grok)

</comment></comment><comment><USER37> >>>open(b'test-\xd8\x00.txt', 'w').close()

Is that a C-string? Does it crash if one forgets the null byte?

<comment><USER38> > Is that a C-string?

It's a Python bytestring.

> Does it crash if one forgets the null byte?

No. But in that case it _will_ crash when you use it as CPython (and most FS APIs, and most FS) don't allow NUL in filenames.

<comment><USER39> It's not going to crash. You'll get an error.

</comment></comment></comment><comment><USER40> It's says bytes is an array of bytes, does the author mean bits?

<comment><USER41> It's a bit of a clunky sentence because of the name conflict between the concept of multiple bytes and the Python data type.

A byte is a sequence of bits, and "bytes" is the name of a sequence of bytes in Python.

</comment></comment><comment><USER42>
        >>> 'おはようございます'[::-1]

Why do people keep using this as an example? A character is not a necessarily a single code point; reversing code points is not any more meaningful than reversing bytes. And reversing strings isn't something frequently needed in practice either.

Let me make this as clear as possible:

        a code point is not a character

        a code point is not a character

        a code point is not a character

I want the author to read that, over and over again, until it sinks in.

</comment><comment><USER43> > The only problem with Python 3's str is that you don't grok it

Sadly this quote shows a fundamental lack of understanding of the problems with the Python 3 string type.

<comment><USER21> Downvoted for surprising lack of substance.

Note I do read many of your blog posts -- and thanks for writing them, there is a lot of insight for me.

I also did read most or all of your blog posts about python3 unicode handling. The thing is, while most or all of the facts presented there are "true", many of the negative conclusions there are just your opinion that stems from years and years of doing it "your way" (I would call it FUD, but I have strong opinions too). Python2's unpredictable implicit conversions are hardly "sane" (that's one of the unjustified claims made there). Do you also call Javascript's "==" sane?

For me Python3 str has worked like a charm for years. I like the strict separation of high and low level affairs. I like how I can treat files as text files (deal only with python3 _str_ s) and don't have to think about low level affairs, or types, or conversions, which is a great boon for scripting. I like how I can drop down to the bytes level when needed and know exactly what I'm at.

For some balance, I wouldn't expect that conversion to python3 is always easy. But I would blame python2 for missing clean concepts, not python3.

Also, it's hardly convenient to code most of a Python3 app at the byte level. But it could be argued that python should not be used for these things.

<comment><USER44> I agree that having stricter coercion rules makes sense in situations where the coercion might be ambiguous, whether adding byte-strings and Unicode strings together is such a case is debatable though (I think it is), as in many cases implicit conversion yields an acceptable outcome. Again, this is more a question of design philosophy, but the thing with Python (2) is that implicit coercion was the default behavior in many cases, so changing that is painful.

Personally I think we should double-down on type annotations and stronger (optional) typing for Python, because the lack of a good type system is by far the biggest obstacle for building robust, large systems in Python.

</comment></comment></comment><comment><USER45> In Python 2.7.12

>>>s = u'おはようございます'

>>>print s[::-1]

すまいざごうよはお

The only problem with Python 2.7 strings is that the author of the article doesn't grok them. Just use u'' instead of ''. There is also "from __future__ import unicode_literals".

<comment><USER46> In both of those cases, you're no longer using a Python 2 string, in that it's not a bytes-like object. For example, you can't write a Unicode object across a socket- it has to be converted to bytes first.

<comment><USER45> unicode is a subtype of basestring. And it existed since the beginning of Python 2, afaik. It's extremely unfair to compare Python 3 strings to Python 2 str, when Python 3 str is just a rename of Python 2 unicode and has basically the same features. And the article doesn't even mention that Python 2 has all the same features.

<comment><USER47> > And the article doesn't even mention that Python 2 has all the same > features.

Because it's not about the fact that you can achieve the same thing. What the article does is illustrate that a thing that returns 'str' when you call 'type' on it in Python 2 is not the same nor can be used in the same way as what Python 3 would call a 'str'.

<comment><USER45> No, if that was the author's intention, he would've simply pointed out that "unicode" was renamed to "str", while "str" was renamed to "bytes" and is no longer considered a string. Instead, he wanted to demonstrate how Python 3 string handling is some sort of a major breakthrough when it's largely a cosmetic change.

<comment><USER48> It's a cosmetic change which happens to completely derail ill-informed Python programmers, so yeah, it's a big deal.

</comment></comment></comment></comment></comment></comment><comment><USER49> So, for example what is The Py3k Right Way to fetch an URL with text content into a string? The example [https://docs.python.org/3/library/urllib.request.html#exampl...](https://docs.python.org/3/library/urllib.request.html#examples) just says "it's complicated, we just know it's utf-8", and even that would bomb out if there's a character spanning the 100 byte boundary.

To me it looks like by insisting on lossy byte/string conversion of all I/O the language painted itself into a corner, with funny "a bytes is not a string" chanting sideshow.

<comment><USER38> The "right way" _in every single language_ is to follow the encoding sniffing algorithm: [https://html.spec.whatwg.org/multipage/syntax.html#encoding-...](https://html.spec.whatwg.org/multipage/syntax.html#encoding- sniffing-algorithm).

You may want to note the following:

1\. implementing the entire encoding-sniffing algorithm for a basic example is a bit extreme

2\. the very first step of the encoding-sniffing algorithm is "if the use has explicitly provided an encoding, use it", which is essentially what the example does

> To me it looks like by insisting on lossy byte/string conversion of all I/O > the language painted itself into a corner

That makes literally no sense. If you want to "fetch an URL with _text content_ into a _string_ " — emphasis on _string_ , not _bag of bytes_ , if you want a bag of bytes you can skip the whole decoding thing in Python it's _not necessary_ — there's no other way than to decode it, which means you need to assert or discover its encoding, for all you know the document could be in Big5.

<comment><USER46> Seriously. It's easy to "fetch a URL with text content into a string" with Python 2 right now _because Python 2 assumes that all bytes are ASCII_.

<comment><USER50> No, it's not! It's easy to fetch a url's content into a bag of bytes. That's it.

If the content of the page happens to contain an emoji (which hey, more and more do) or even a friggin' unicode double-quote mark, then you're no longer fetching it into a valid string, if you take string to mean faithful textual representation. You've got all the bytes there, but you can't interpret it correctly.

This is a real problem that has caused real pain for me with various tools written in python2

</comment></comment></comment></comment><comment><USER51> I've got nothing against Python3. But recognize that Python3 got itself into this mess by being incompatible with Python2. It's different language, albeit superficially similar to Python2. Python3 should have been given another name like "Bob" or something. Ditto for Perl6 vs Perl5 and Angular2 vs Angular1.

<comment><USER31> Everyone is running around talking about semver, but then tell you that you're supposed to rename your project when you do breaking changes? Sure.

And it's not like there was no early announcement that it won't be 100 % compatible. That was officially announced 10+ years ago.

<comment><USER51> It's not a matter of lead time in announcing it. If it's not backwards compatible then it's a different language. I can still run 20 year old C code in a modern C compiler.

<comment><USER52> In languages, this is accepted practice. Was Perl 5 backward compatible with Perl 4? Or C11 with C99? Or even C99 with C89, or K&R C?

If you use reasonable and forward-looking language constructs, it will be runnable – or at least very easy to port to – newer major versions of the language. This is also true for the transition from Python 2 to Python 3. The problem is that _a lot_ of people used (and still use) Python 2 badly.

<comment><USER51> > Was Perl 5 backward compatible with Perl 4? Or C11 with C99? Or even C99 > with C89, or K&R C?

Yes.

<comment><USER31> Actually, no.

There are many differences between K&R/UNIX C and C89. For example, in K&R string constants could be modified, and repitions of the same constant would be different strings. This is not the case in C89. Variadic functions are different. Octal numbers were changed. Arithmetic works differently. And so on.

I can't comment on Perl 4 vs 5 vs 6.

<comment><USER53> The latest version of Perl 5 is almost entirely backwards compatible with every earlier versions of Perl 5. ( There are some features which almost no- one used, that also should never be used that were eventually removed )

Perl 5 is backwards compatible with Perl 4

Perl 4 is just a renamed version of Perl 3 to coincide with the release of the book "Learning Perl"

Perl 3 is backwards compatible with Perl 2

Perl 2 is backwards compatible with the original Perl

Many of the problems that new Perl programmers have with learning Perl is that every new feature had to be added in a way that it didn't break existing code. That is why for example you have to add "use strict" and "use warnings" to every Perl source file, even though that should be the default.

Perl 6 exists because we "wanted to break everything that needs breaking", so it is very different than any previous version.

That is why both Perl 5 and Perl 6 will both continue to be supported languages.

Imagine taking good ideas from every high level modern programming language, bringing them all together, while making the features seem like they have always belonged together. That is Perl 6.

I like to say that as Perl 4 is to Perl 5 is to Perl 6, C is to C++ is to Haskell,C#,smalltalk,BNF,go, etc

</comment></comment></comment></comment></comment></comment></comment><comment><USER54> Oh I grok it just fine, it just sucks horribly.

I may be missing something "pythonic" but casting between byte strings and ascii strings - a null operation - is by _far_ my greatest cause of runtime bugs.

To make it worse, the obvious cast is broken beyond all belief. What do we get from str(b'hello world')? Literally "b'hello world'" \- a __repr__ of the object. Of course, adding an encoding changes the actual functionality of the cast ... str(b'hello world', 'ascii') gives 'hello world'. So, so broken.

<comment><USER55> You don't grok it. Bytes are not ASCII strings. They are NUMBERS between 0 and 255. Strings are strings. DECODING bytes with ASCII encoding into TEXT is not "casting", it's DECODING.

<comment><USER21> I wouldn't say they are not ASCII strings, because they are if you squint.

Better say "bytes are not Unicode strings".

<comment><USER55> No, they are NOT strings, they are not any kind of strings. They are bytes:

        >>> b'asd'[0]
        97
        >>> b'asd'[1]
        115
        >>> b'asd'[2]
        100

They happen to contain an ASCII DECODABLE string in this case, but to get the text back, you NEED TO decode it first:

        >>> text = b'asd'.decode()
        >>> text[0]
        'a'
        >>> text[1]
        's'
        >>> text[2]
        'd'

<comment><USER21> Technically true. I'd inferred a different context on this one: By "strings" I meant the abstract concept in this case, not the python _str_ which is the one meant.</comment></comment></comment></comment></comment>


Ask HN: Learning resources that finally helped you grasp a complex topic? - <AUTHOR> When talking with people about certain topics that are complex it can be easier to reference a blog post, video, or something else. For me, this is usually happens when I had difficulty grasping a certain concept until it was explained to me a certain way.<p>Here are a few resources that finally helped me grasp certain concepts:<p>- Javascript event loop: https://www.youtube.com/watch?v=8aGhZQkoFbQ<p>- Javascript closures: https://www.robinwieruch.de/javascript-closure/ <comment><USER2> What are you asking for?

I think it would be more effective to ask about a specific topic.</comment>


Re: Linux Date Command gives wrong year with +%g - <AUTHOR> http://lists.gnu.org/archive/html/bug-coreutils/2010-01/msg00008.html <comment><USER2> It's wrong in the sense that not the obvious result users expect. But it's 100% technically right.

It's always tough to deal with this kind of situation. Do you document it all over the place and hope users read it? Do you parse the command when it's first created and warn the user that %g is different than %Y? Do you just ignore the issue and deal with the small number of emails at the beginning of every year?

I think a combination of docs + automated checks is best depending on the circumstances.

</comment><comment><USER3> Probably "wrong" here should be in scare quotes. It's not the wrong year; it does return the correct ISO year. It's just that ISO year is not what you want so you should be using %y rather than %g.

<comment><USER4> Check the actual link: that's exactly what the email linked to says. (And the title here is simply the title of the email.)

I'm assuming that (1) the poster is warning others about this or (2) he finds it amusing that the response to "The year is wrong" is (roughly) "No, that's how the standard defines year. The output is right relative to that standard. Dates and times suck." (the last sentence is implied) or (3) both.

</comment></comment><comment><USER5> Here is how strftime on OSX defines it:

         %G    is replaced by a year as a decimal number with century.  This
               year is the one that contains the greater part of the week
               (Monday as the first day of the week).

         %g    is replaced by the same year as in ``%G'', but as a decimal
               number without century (00-99).

Makes sense to me. People should read the man pages more often before they jump to conclusions.

Granted, that is more clear than man date on Linux (on OSX it doesn't define the format variables):

           %g     last two digits of year of ISO week number (see %G)

           %G     year of ISO week number (see %V); normally useful only with %V

           %V     ISO week number, with Monday as first day of week (01..53)

</comment><comment><USER6> %g tells you the year (modulo the century) in which the current week's Monday took place

</comment><comment><USER7> when would you actually want to use an ISO year though? just to claim ISO compliance?

<comment><USER8> Things get weird if you use weeks as a unit and then also display the year. For example, if you have an event that took place on 2010-01-01, then iso_week_of(2010-01-01) will return 53 and year_of(2010-01-01) will return 2010. So your wonderful app might display "Week 53, 2010", which makes it look like it's the end of 2010.

</comment></comment><comment><USER9> Can someone please explain what ISO years are and when the correct time to use them is?

<comment><USER10> International Standards Organization years; standardizing date-time formats across various UNIX systems. Many people from Europe, for example, prefer the month to be stated after the day of the month. "2 January YYYY" whereas in other places (in formal writings) people prefer the month to be written first: "January 2, YYYY". Sometimes (if, for example, running virtual host) they can appear to be a mix-up since there's quite a bit of ambiguity within the %m%d%H%_M% or "%m%d%H(M)" string sequences.

For sources, see also "errata" on intuitive.com/wicked

 _when the correct time to use them is?_

Basically amounts to personal preference since options can be formatted.

<comment><USER6> That doesn't really answer the question they were trying to ask, but other replies do.</comment></comment></comment>


Could the EU break up Facebook's monopoly? - <AUTHOR> https://www.handelsblatt.com/today/politics/legal-eagles-could-the-eu-really-break-up-facebooks-monopoly/23582226.html?ticket=ST-604937-KINlt255WmEXg5XJbzOJ-ap3 <comment><USER2> I would be more worried about Facebook breaking up the EU, the EU might have a history of breaking up monopolies but Facebook also has a history of affecting the outcome of elections and lest we forget Brexit.

<comment><AUTHOR> Very interesting thought. This is why I share things here, I always learn more from what other humans think.

I am trying to understand how far political power can even go against a force this subtle and pervasive? This is not the 1990's and this is not Microsoft, this is much deeper now.</comment></comment>


Ask HN: Need help to Decipher a Line for school assighment - <AUTHOR>

ZYEMOUSOUSIZWYIXOKSOTZQSOBSYLSWDKHTMOWARMSKSRRSILISFESWBHSTOISQISRRZWSOIRYRMSOUSIODSTLYISWDKHTMOWAWYEWBYXXYWSWDKHTMGYIATOISQISTSWRRMSYRMSIRSVRTGHKKWYRJSTYSOTZOWAXOZJSMOIARYAYJISONHWDRMHTBHQMSIJZMOWATMYEKAWYRJSAHLLHBEKRRYAYMYGSUSIRMHTSVSIBHTSOTNTZYERYGIHRSOQIYDIOXRMORORROBNTBHQMSITOERYXORHBOKKZOWAJISONTRMSXGHRMYEROETSIMOUHWDRYPEXQHWOWAXONSOBMOWDSOTHXQKSJIERSLYIBSOQQIYOBMHTWYRWSBSTTOIHKZRMSWHBSTRGOZRYAYWSRMHTRMSRIHBNRYAYHWDRMHTGHKKJSRYASRSBRGMSWRMSTEJTRHRERHYWHTWYRIHDMROWARYLHWAOJSRRSIYWSETHWDRMSLISFESWBHSTRYDEHASZYEDYYAKEBN<p>This is the text to decipher please help if anyone can.. or tips how i can solve this <comment><USER2> Z is not a space, nor is N. That's all I've got for you, buddy. I can think of some code that would help, but I don't have time to write it.

Were you told that this is a traditional cipher, where characters are substituted 1:1?

Generally speaking, thinking really hard about this (and possibly failing) is going to be better for you than having someone on HN tell you the answer.

</comment><comment><USER3> looks to me like the distribution of characters follows the normal distribution of alphabetical characters.. i suspect its a substitution cypher</comment>


GHC 8.2.1 available - <AUTHOR> https://mail.haskell.org/pipermail/ghc-devs/2017-July/014422.html <comment><USER2> Has anyone switched to the LLVM backend, or do most people still use the default backend?</comment>


Encryption App 'Signal' Fights Censorship with a Clever Workaround - <AUTHOR> https://www.wired.com/2016/12/encryption-app-signal-fights-censorship-clever-workaround/ <comment><USER2> I found the linked article on [domain fronting][0] to be very interesting.

[0]: [https://www.bamsoftware.com/papers/fronting/](https://www.bamsoftware.com/papers/fronting/)

</comment><comment><USER3> Next step for egypt could be to MITM the whole country's traffic</comment>


Latin America is set to become a leader in alternative energy - <AUTHOR> http://www.economist.com/news/americas/21711307-power-andean-sun-latin-america-set-become-leader-alternative-energy?fsrc=scn/tw/te/bl/ed/latinamericaissettobecomealeaderinalternativeenergy <comment><USER2> FWIW I made a map this year about Non Fossil electricity usage around the world and the results are quite surprising actually, supporting the article for the most part. Btw. this was surprisingly quick to do with google spreadsheets.

[https://docs.google.com/spreadsheets/d/16K4gNhy_AN8Eg4Ov3z7p...](https://docs.google.com/spreadsheets/d/16K4gNhy_AN8Eg4Ov3z7pF_dgON1oObkHQ8Px5I73Hvc/pubhtml#)

<comment><USER3> You can stand to it as you wish but by which means is nuclear power a renewable? (See France with 91%+ renewable with mostly nuclear power)

Edit: Or non-fossil, if that is a difference

<comment><USER2> After your edit, does your question really make sense to you still? Of course nuclear is non fossil?

And yes, whether we go full renewable or a mix of nuclear and renewable is IMO a second order question, the main focus should be carbon neutral to negative economy ASAP.

<comment><USER3> Well, only if you are pedantic with fossil meaning long dead organic (which is true, of course). But for energy it makes more sense to distinguish between sources that can be used or they are gone (sun shines on the planet and at some point the heat dissipates back into the universe) and those that are gone at some point because we have used them. So, yeah, point taken, but then I do not think it makes much sense to distinguish between fossil and non-fossil for the point you want make here, which is dependence on a time-limited resource.

<comment><USER2> I disagree on your last point. By far our biggest problem right now is to keep the climate stable enough. Earth's carbon absorption rate is the most critical resource we have, not the amount of non renewable energy resources that are left. The first problem we have to solve within 1-20 years max., the second is more like 100-500 years (Uranium/Thorium/Plutonium/Fossil Fuel that's available).

</comment></comment></comment></comment></comment><comment><USER4> Calling it "alternative energy" always strikes me as a bit silly. It's an alternative source, the energy stays the same.

From my limited research into energy sources, both solar and wind seem like good short-term goals. The fundamental problems with both seems to be that it's not viable in many locations and it's not steady or predictable. With the space craze that has started developing in the last few years, I'm hopeful people will open up more to the idea of nuclear power. Nuclear is our only path to the stars!

The article left me with more questions than answers. How do they define being a "leader in alternative energy", and why is it important? They don't provide enough evidence to prove this is the case. How do their efforts compare to other countries around the world? What effects would we expect this have on the host country? e.g. improved economy, quality of life, etc.?

<comment><USER5> Nuclear is too slow and too expensive. Even once you get past the permitting objections, it takes a long time to build the plants. And building nuclear plants in countries that don't currently have any is extremely problematic because of the arms proliferation question. I suspect that's a big factor in South America.

I don't really see what nuclear has to do with space. Our short-to-medium term life is a question of keeping Earth safe, both politically and environmentally. While the energy costs of rockets are individually huge they're still not a significant percentage of our global energy consumption.

The uplands of Chile, Peru, Bolivia etc are particularly suitable for solar, entirely viable and cloudless for most of the year. I've been to the altiplano: this [https://www.flickr.com/photos/136766297@N06/21300817773/in/a...](https://www.flickr.com/photos/136766297@N06/21300817773/in/album-72157657104598053/) is a short drive from La Paz, 4000m above sea level and 16 degrees south of the equator. Ideal landscape for solar farming.

Edit: just remembered, while I was there I saw the floating islands of Lake Titicaca, which is an incredible way for people to live; a sort of houseboat built of reeds. The only modern convenience was a TV ... powered from a solar panel and car battery.

Solar hot water is also already ubiquitous at that latitude - all you have to do is put a black barrel on your roof.

<comment><USER6> > _While the energy costs of rockets are individually huge they 're still not > a significant percentage of our global energy consumption._

The limiting factor for chemical rocket propulsion is not the total energy consumed, but the specific impulse (the "mileage", i.e., efficiency). This is because rockets have to carry and accelerate all their fuel with them, leading to the size of the rocket growing exponentially with the speed you want to reach. For nuclear propulsion, it's still exponential, but the exponent is much smaller.

Furthermore, electricity generation using solar panels quickly becomes infeasible with growing distance from the sun.

</comment></comment></comment><comment><USER7> While riding in an Uber through Washington DC, my dad and I had a chat with the driver about his plans to build two solar installations in the US.

He also mentioned the likelihood that their company would soon enter Latin America, where higher electricity rates for consumers would allow them to make more money for selling the same amount of electricity compared to the US. He said this was the main angle he was using to attract investors.

<comment><USER8> I'd be curious to understand how driving a Uber fits into that strategy.

<comment><USER9> Maybe driving a Uber in Washington DC lets you meet some interesting/useful people?

</comment></comment></comment><comment><USER2> Right now I'm most worried about two places when it comes to carbon footprint: US and India. The US is very worrysome now, India in a decade or two. China is worrysome as well, but at least there you can see progress being made on a national scale, which can't really be said yet about the US, and with a Trump administration I'm afraid that even commercial attempts could be spoiled again with an artificially propped up fossil fuel economy. If that happens it's borderline suicidal really.

<comment><USER10> Just a few days back India installed a huge solar electricity generation project in Tamil Nadu, we have a working smart grid in place like Latur, in the next 2-3 years there is a mandate that all railway platforms shall use solar energy. I think India is taking solar energy seriously. Upto this limit that Indian PM and transport min went to meet Musk about starting Tesla manufacturing in India for Asian markets!

<comment><USER2> I wasn't aware of this, thank you for the heads up. India is critical - hundreds of millions of soon-to-become energy consumers, it's imperative that gas/coal gets trumped by alternative thats both carbon neutral and cheaper.

If India gets this right the next bigger problem will be Indonesia - unfortunately with a much more worrisome government.

<comment><USER10> Yes, even I was unaware of this, it was after meeting a lady who lived in Latur that I realized that we have a smart grid working. They have to install solar panels, use electricity and if excess is generated they can sell it to the grid

although, I will say, not a lot of people are using it because of the cost. Money and cost are interpreted in a funny way in India, you ignore it when you do what you like and tend to think too highly of it when you do something you don't want to do.

For instance, a typical Indian lady would go xx km to get a short discount on clothing, they'll spend more $ on fuel as compared to the savings they'll get due the the discount, but that's fine. When it comes to installing solar, which will pay itself out within a few years, "no, it costs a lot of $$". It is here that we face deadlock, unless everyone else does it, we don't do it.

One positive highlight I'd like to do is that most of India uses solar water heater, at least we have that. Plus with Tesla, I hope we get to a point where solar panels are cheap, and we can store a lot of electricity and not require special cabling for the solar electricity, everything should be a drop in replacement, plus, solar panel prices are said to drop steeply.

We are living in interesting times!

</comment></comment></comment></comment><comment><USER11> The most important part of this article was a mention of connecting national grids. If we had a global grid, the section of earth with enough sunlight could power the rest of the world. And hence no need for non-renewable energy.

<comment><USER12> Well, transmitting all this energy is not that trivial, that's the point..

</comment></comment><comment><USER13> This is an interesting setup -- because the example solar plant is in Chile, which has a LOT of hydropower, they can plug in a lot of wind and solar without having to worry as much about storage.

<comment><USER14> Well, is not as simple as it seems.

Indeed, here in Chile we have a lot of hydropower, but the overwhelming majority of it is located on the center and south of the country (where most of the population lives), while the big solar projects are located on the north (where most of the mining activity happens).

Being such a long country this means that there are big distances between hydropower and solar plants (1500+kms) rendering inefficient to make use of combined energy sources due to energy loss on the transmission lines and the cost of building these transmission lines.

In fact, the power grids of the north (SING) and the power grids on the south/center (SIC) are not yet connected [0], causing a huge excess of energy on the north system due to the recent addition of solar plants. The excess of energy is being sold to Argentina [1] instead of being used on the south, making me wonder what interesting things we should be doing with this excess... (mining bitcoins, datacenters, etc).

[0] [http://www.nuevamineria.com/revista/se-nos-viene-la- intercon...](http://www.nuevamineria.com/revista/se-nos-viene-la- interconexion-sic-sing/) [1] [http://fen.uahurtado.cl/2016/noticias/quien-lo- diria-chile-e...](http://fen.uahurtado.cl/2016/noticias/quien-lo-diria-chile- exporta-energia-electrica-y-gas-a-argentina/)

</comment></comment><comment><USER15> When you sell energy, you have a share of everyone's money, because energy is needed for everything.

Solar energy will take a lot of that advantage away and that should create an overall better world.

<comment><USER16> Though I think the world is going to be a better place. We're headed for a very difficult political reality in my lifetime. We have a whole lot of challenges coming up, and our leaders don't know what to do about them.

<comment><USER17> Luckily, on our current trajectory, its not as bad as you'd think. Even without additional political support, clean energy can finally stand on its own.

TL;DR The question is no longer if we'll make it, just when.

* Solar and wind are stupid cheap now, and getting cheaper, fast. In over 25 states, rooftop solar is a better investment than the S&P500. [1] You're seeing Power Purchase Agreements under 3 cents/KwH. [2] Solar will only get cheaper. Wind is still being built like crazy in Texas and the central Midwestern US. Some utilities even offer power for free at night wind power is so plentiful (and transmission capability lacking). [3] Tesla/SolarCity has already moved into Florida now that the utility-sponsored Amendment 1 failed. (Which was an underhanded utility attempt to hinder rooftop solar deployment)

* Utility scale battery storage has arrived. Again, its only going to get cheaper (Tesla's Gigafactory is a big deal, but lots of other players in the market as well) [4] [5] [6]. Tesla has already installed a microgrid on an island in the Pacific that satisfies all of the island's power needs, removing the need for their diesel generators to produce island power.

* Tesla will deliver its Model 3 in the next 12-18 months. I have no doubt Elon will drive Tesla into scaling up to 1 million vehicles/year in production (relying primarily on their recent German manufacturing automation acquisition) [7]. While I would like to see Nissan and GM make EVs that aren't purely compliance cars (Bolt? Pleasssssse), I think they're good enough for urban dwellers or car share networks where you're sticking to major metros. (Full disclosure: TSLA investor)

* OPEC has finally agreed (after 8 years) to reduce supply to push oil prices back up. Even with US shale coming back online at those profitable market prices ($60-80+/barrel) and some of OPEC cheating on those cuts (who wants to reduce their revenue artificially?), that only does one thing: accelerates the transition to EVs. [8]

* Repealing the Clean Power Plan will not be able to stop the phase out of coal power due to cheap natural gas. Market forces at work. [9]

* Federal electric vehicle subsides will phase out within the next 2 years for all manufacturers due to hitting the sales quotas dictated by the statute's phaseout provisions [10]. No point in trying to remove them.

* Solar and wind ITC tax credit extensions (to 2021) agreed to by Congress were bipartisan. In exchange, restrictions were removed on the export of crude oil from the US. This agreement will not be unwound.

[1] [https://solarpowerrocks.com/infographics/solar- infographic-s...](https://solarpowerrocks.com/infographics/solar-infographic- state-solar-investment-returns/)

[2] [https://www.bloomberg.com/news/articles/2016-05-03/solar- dev...](https://www.bloomberg.com/news/articles/2016-05-03/solar-developers- undercut-coal-with-another-record-set-in-dubai)

[3] [http://www.nytimes.com/2015/11/09/business/energy- environmen...](http://www.nytimes.com/2015/11/09/business/energy- environment/a-texas-utility-offers-a-nighttime-special-free- electricity.html?_r=0)

[4] [https://www.bloomberg.com/news/articles/2016-09-15/tesla- win...](https://www.bloomberg.com/news/articles/2016-09-15/tesla-wins-utility- contract-to-supply-grid-scale-battery-storage-after-porter-ranch-gas-leak)

[5] [https://electrek.co/2016/10/25/tesla-powerpack-first-grid- sc...](https://electrek.co/2016/10/25/tesla-powerpack-first-grid-scale- powerpack-installation-asia-pacific/)

[6] [https://electrek.co/2016/11/22/tesla-island-microgrid- batter...](https://electrek.co/2016/11/22/tesla-island-microgrid-battery- solar/)

[7] [https://electrek.co/2016/11/08/tesla-acquires-german- enginee...](https://electrek.co/2016/11/08/tesla-acquires-german-engineering- firm-create-tesla-advanced-automation-germany/)

[8] [https://www.bloomberg.com/news/articles/2016-11-30/opec- said...](https://www.bloomberg.com/news/articles/2016-11-30/opec-said-to- agree-oil-production-cuts-as-saudis-soften-on-iran)

[9] [http://www.utilitydive.com/news/tva-ceo-clean-power-plan- com...](http://www.utilitydive.com/news/tva-ceo-clean-power-plan-compliance- natural-gas-part-of-future-strategy/431143/)

[10] [https://cleantechnica.com/2016/04/19/how-the-ev-tax- credit-w...](https://cleantechnica.com/2016/04/19/how-the-ev-tax-credit-works- tesla-model-3/)

<comment><USER18> Solar is less than 1% of electricity:

[https://www.eia.gov/tools/faqs/faq.cfm?id=427&t=3](https://www.eia.gov/tools/faqs/faq.cfm?id=427&t=3)

Current projections have the United States at 10% solar power by 2025:

[https://en.m.wikipedia.org/wiki/Solar_power_in_the_United_St...](https://en.m.wikipedia.org/wiki/Solar_power_in_the_United_States)

"A report finds that solar power's contribution could grow to 10% of the nation's power needs by 2025:"

I don't think that's enough clean energy to make a sufficient difference.

My feeling is that if we were on a good trajectory, Bill Gates and friends wouldn't be looking to create a huge fund for more research:

[http://qz.com/859860/bill-gates-is-leading-a- new-1-billion-f...](http://qz.com/859860/bill-gates-is-leading-a- new-1-billion-fund-focused-on-combatting-climate-change-through- innovation/?linkId=32225791)

Being discussed here:

[https://news.ycombinator.com/item?id=13155146](https://news.ycombinator.com/item?id=13155146)

<comment><USER17> 93% of new generation capacity coming online each month is from renewables, according to the EIAs "Electric Power Monthly" and "Electricity Monthly Update" reports.

[http://www.eia.gov/electricity/monthly/#tabs_unit-4](http://www.eia.gov/electricity/monthly/#tabs_unit-4)

[http://www.eia.gov/electricity/monthly/update/](http://www.eia.gov/electricity/monthly/update/)

<comment><USER18> I think you're reading it wrong:

[http://www.eia.gov/electricity/monthly/epm_table_grapher.cfm...](http://www.eia.gov/electricity/monthly/epm_table_grapher.cfm?t=epmt_es1b)

Natural gas: 1,087,236 1,011,464 7.5%

Solar: 28,058 19,684 42.5%

A lot more natural gas came online than solar. The solar percentage is so high because it's an increase over a much smaller number.

<comment><USER17> EDIT: I included natural gas in the total generation mix. That's my mistake.

I don't discount additional natural gas coming online; that's a good thing. It throttles faster than nuclear and coal, and produces far less CO2 than coal generation. Natural gas is almost a requirement as renewables scale up until batteries for utility scale storage have dropped in price to be competitive. This is already happening: Tesla is contracting with several utilities to replace their natural gas peaker plants with battery storage substations.

[http://www.eia.gov/todayinenergy/detail.php?id=25172](http://www.eia.gov/todayinenergy/detail.php?id=25172)

"Electric generating facilities expect to add more than 26 gigawatts (GW) of utility-scale generating capacity to the power grid during 2016. Most of these additions come from three resources: solar (9.5 GW), natural gas (8.0 GW), and wind (6.8 GW), which together make up 93% of total additions. If actual additions ultimately reflect these plans, 2016 will be the first year in which utility-scale solar additions exceed additions from any other single energy source."

<comment><USER18> United States 1,068.4 Gigawatt

It doesn't make sense to include natural gas. We added 15GW of renewable energy to our 1068 GW. We really need to do a lot better. Your optimism is unfounded.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> haha this better be a fuckin joke down here everything is coal poweered

<comment><USER20> This account has been posting only uncivil and unsubstantive comments, and we ban those that do this. Please read the welcome page and guidelines:

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>