Google's cross-platform Flutter UI toolkit goes 1.0 - <AUTHOR> https://techcrunch.com/2018/12/04/googles-cross-platform-flutter-ui-toolkit-hits-version-1-0/ <comment><USER3> Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing. [https://github.com/flutter/flutter/blob/master/examples/plat...](https://github.com/flutter/flutter/blob/master/examples/platform_channel/lib/main.dart)

Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.

We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time.

So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.

<comment><USER4> > We are on the verge of VR and AR and I don't see how flutter can help e.g. > processing >100fps Video Feed using OpenCV library. The demo they presented > on stage with ML and smile detection had quite big latency. I wouldn't call > it real time.

I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against Javascript interpreted code which is far from fast by any metric.

> So far it seems the easiest way to call c++ functions is using ObjC++ or Qt > framework.

On mobile? Qt really isn't pleasant or usable on mobile.

<comment><USER3> I have recently gave a look at Qt after 5 years and it seems lots of things have changed for the better. You get the same hot reload like flutter when modifying GUI using QML (with V-Play you can even hot reload not just on simulator/emulator but on real device). Qt material theme has good look and feel. Sadly iOS theme is a little bit lacking.

C++ is probably not the most productive language to write business logic but on the bright side Qt Company recently started supporting Qt for python (Pyside2) - sadly not on mobile devices for now. However it seems you can use PyQT5 on mobiles nowadays. This would be the best of all worlds IMO: 3 highly popular languages with rich libraries, tools and ecosystem -> C++ for speed critical code, Javascript/QML for UI and layout, Python for business logic and as a glue.

Qt also gives me more confidence that is not going away anytime soon. It survived many years and acquisitions (Trolltech, Nokia, Digia) and have some big clients/users in automobile and open source (KDE).

I will closely follow Flutter thought as well as React Native. The latter one also it seems noticed what a pain is writing all those bridges and looks like they are working on it to fix it with new architecture.

<comment><USER5> Sadly, Qt has so many threats on their download pages that I feel it's only suited to companies that can keep full time lawyers on payroll...

<comment><USER6> What? Qt is mostly LGPL. You don't need a lawyer.

<comment><USER5> Try to download it from qt.io. You will have to go through several screens saying "Are you sure you are able to comply with the LGPL? Wouldn't you rather get the commercial version for peace of mind?". If that isn't an implied threat, i don't know what is.

<comment><USER7> I don't approve of that tactic (in fact it drives me nuts), but I will say, Qt's license fees are quite reasonable, and then you get to link statically with no risk of violating the GPL.

<comment><USER8> Reasonable? It's about $500 / month / developer with additional royalties if you are shipping devices with Qt firmware. Sure I think Qt/QML is the best UI toolkit available but this crazy pricing is driving me towards any possible alternative. So I'm really hoping Flutter will take off (for desktop/embedded as well, not only mobile).

Note that Qt is GPL3 nowadays so you can't really ship embedded devices with Qt without paying.

<comment><USER9> A great toolkit like Qt, including Qt Creator and UI designers, doesn't get written during late nights and weekends.

They are pretty cheap considering the typical prices on their target markets, embedded tooling, medical devices, enterprise solutions.

Naturally they decided to pivot to those markets, as Trolltech has hardly seen any significant monetary profit from FOSS.

So it is only fair that those that don't want to pay, also ship code free to the others.

<comment><USER8> Most embedded tooling is free nowadays. Free software has eaten the world and will continue to do so.

I will use a free UI toolkit when I can. Qt will kill itself with their current pricing model.

Automotive is moving towards Android. Qt is not good for medical either because it is not really certifiable.

<comment><USER9> Actually what I predict is the return to shareware/public domain models, where the free software is only the tip of the iceberg of the stack one actually needs for production code.

The trend is already visible with SaaS, Cloud, IoT,...

Qt is certainly certified for medical use, [https://www.qt.io/qt-in- medical/](https://www.qt.io/qt-in-medical/).

I have hardly seen any big Android Auto adoption.

The biggest foe of Qt in Automotive is Web stack.

<comment><USER8> Ok I'll admit I'm not familiar with medical certification. I know that the so called Qt Safe Renderer for ISO26262 compliance is a bit of a joke at least.

I have seen two very big Qt projects being cancelled due to Android. Not the Android Auto app but native Android for IVI.

I don't see any indication of your vision for shareware. The trend is towards more and more software being licensed under licenses such as MIT.

<comment><USER9> > The trend is towards more and more software being licensed under licenses > such as MIT.

Which is exactly my point.

Give the tip of the iceberg for free, charge for everything else and give as little back to upstream, if anything.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Cross-platform frameworks that don't use native controls have suffered from problems...

\- They inevitably don't look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn't work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)

\- they don't get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn't get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.

\- Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today's systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.

\- there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.

\- dealing with the cross-platform issues the framework doesn't solve becomes very difficult for the app developer. They've got to find a way in, through, or around the framework (in an area it already isn't handling well).

\- devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.

\- many potential third-party tools will have native support and bindings but most won't make accommodations for your framework, so you end up having to support that yourself, or do without.

Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you're doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can't find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).

<comment><USER11> > _\- They inevitably don't look or work like native apps in ways both big and > small, frustrating and annoying users._

We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).

<comment><USER12> To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example:

\- Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable) power of share sheets to do things like sending an article to another app or take an action on it.

\- Gsuite doesn't register left swipe as back even though 99% of apps on iOS do. Icons for common actions are subtly different and make you double-take while you understand what they do. Accessibility options like larger text do not work, so if you're vision impaired good luck trying to figure out what you're looking at. And there's a ton of other quirks that have existed over the years including scaling to new resolutions/ipads, problematic text selection, performance, etc. It's not as bad as it used to be, but it's still not a pleasure to use Gsuite or any material design on iOS.

While many apps may use cross-platform frameworks solely for saving developer/designer time, the bigs use them for an additional strategic purpose that is detrimental to users.

\- Google wants you to be familiar with their apps regardless of platform, so that its easier to get you to switch to Android or Chromebooks.

\- Facebook wants to keep you in the app as long as possible, limit social sharing outside of their app, and spy on your browsing activity, so they add friction and don't use modern iOS web views that prevent that.

I wouldn't take cues from the bigs and just assume because they do it, it's the best course of action.

<comment><USER13> It depends on what you mean by best.

For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren't actually interested in making it feel exactly like a native iOS or Android app.

<comment><USER14> Well, such things are causing subtle annoyance for users. This works as long as the value you provide is good, but the more and app is just a bad we view the more likely it becomes that people uninstall it or look for alternatives. Unsurprising consistent behavior is a value.

<comment><USER15> > Unsurprising consistent behavior is a value.

Looking at the last 30 years of software development, it's pretty clear that users don't care very much.

<comment><USER16> They do care. Try writing a DOS or Blackberry-style app today and see what happens. Software today has internalized the idioms so much that its developers don't even realize it.

"My app is a snowflake and needs a custom design language and UI." You're vim or Photoshop or AutoCAD or Excel: you're targeting dedicated users who are prepared to invest in learning a specialized UI. Fair enough.

But if you're not one of these highly professional apps, then custom control just makes the app less predictable, harder to use, and often inaccessible for users with disabilities. Not good.

<comment><USER17> Website (+responsive mobile sites) have been using custom UIs for years and no one bats an eye

A framework for mobile uses custom UIs and everyone loses their minds?

<comment><USER12> 1\. People _regularly_ complain about inconsistent web UI.

2\. Even web apps often have similar idioms and patterns to their UI that they've settled on. It's their own patterns that are different from desktop OS, it's basically another category.

3\. Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.

<comment><USER18> Many "native apps" are just "hidden" web apps, users just don't know it.

<comment><USER19> Such as?

<comment><USER18> Every Cordova ([https://cordova.apache.org/](https://cordova.apache.org/) -> search for showcase) or PhoneGap ([https://phonegap.com/app/](https://phonegap.com/app/)) app.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I have made an (unofficial/private clone of) Azul boardgame in Flutter (intended as a christmas present to my wife).

Whithout having any Dart or frontend or UI experience (I have always progammed backend and CLI apps), I could make a simple working game in maybe 10 hours - and it is mainly due to the instant feedback cycle.

The whole thing is less than 600 lines of Dart code. (and about 100 lines is to deep copy game state objects (for the undo functionality) as Dart can't do that automatically.

The design is simple, just circles, shadows and small animations (the player in turn gets magnified)[1], but with zero experience in the UI domain I actually barely beleive that I have made it ;)

Of course games are absolutely not affected by the native or not native widget issues, and also I did not use any advanced services from the platform, so can't say much about those weaknesses.

I was really happy with it, I would definitely recommend it to similar hobby/beginner projects.

[1] [https://pasteboard.co/HQdDD4r.png](https://pasteboard.co/HQdDD4r.png)

</comment><comment><USER21> Flutter looks amazing!

I was looking for some new dev challenges and wanted to mess with some mobile app development that is outside of the React Native / Ionic / js world.

Gave Flutter a serious look, loved it, but ultimately decided to just skip and mess with Swift and Apple's tools - so no Android stuff for me for now. I just don't trust it to be around long enough to be an investment for me.

I know I'm just 1 developer working on a crappy hobby app for fun, but Google's quick lifecycle of products has real impact. But then on the other hand I love Firebase. Just wanted to share.

<comment><USER22> "I just don't trust it to be around long enough to be an investment for me."

Normally I would be inclined to agree with you given that this is Google, but the good news is that Flutter is open source. So even if Google discontinues internal development on it, it's likely that the community will continue it anyway.

<comment><USER23> Dart (the lang used in Flutter) already failed to gain traction in the web dev community and nobody seems to be maintaining it there.

<comment><USER24> > Dart (the lang used in Flutter) already failed to gain traction in the web > dev community and nobody seems to be maintaining it there.

Dart for web underlies Hummingbird, Google's Flutter-for-web effort that was also announced as a sneak peak alongside the Flutter 1.0 announcement, so Dart for web is very much alive and maintained at Google.

<comment><USER23> You're missing the point. OP asked what would happen if Google abandoned the project, and it's pretty obvious Dart would die as it being maintained by Google, not the community.

</comment></comment></comment></comment></comment><comment><USER25> I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work.

UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.

The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.

<comment><USER26> I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.

<comment><USER27> > I assume things have changed since then

Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast.

> but I wonder by how much and if Flutter's workflow skirts any of these > issues altogether.

Flutter uses the regular Android emulator, and although you have more editor choice the recommended was to just use a plugin for Android Studio.

<comment><USER7> Is there any alternative to XML? How often do you find yourself hacking XML directly?

<comment><USER27> Your layouts & styles are typically all in XML. But honestly I don't find it bad - it's not "proper" XML, so there's not a ton of cruft. It's really more like XHTML.

It works fine.

</comment></comment></comment></comment></comment><comment><USER28> Flutters Hot Reloading has spoiled me forever.

I am a C++/mobile dev and I couldn't get myself amped about React Native because you have to do all the layouts through style-sheets. I am not a web dev, so style-sheets are pretty foreign to me beyond the basics. With flutter I can do all the same stuff but with auto-complete and in a hierarchy I understand.

I do wish the controls were native, but the customization you get instead is pretty powerful.

<comment><USER29> Haven't tried Flutter yet, but I feel the same way ever since React/Vue hot reload. It's a game changer. I really really miss it whenever I'm working on a site or game that doesn't support it. Once you get used to it, it feels painfully slow developing without.

</comment></comment><comment><USER30> Look at how many comments on this, or any other Flutter thread, mention hot reload.

What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else.

Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more done with a crappy tool with 500ms compile time versus a perfect tool with 10s compile time.

<comment><USER31> I believe rapid iteration (and learning curve) is what made php and javascript (and delphi, anyone?) that popular.

I'm happy there's another platform but they really should use some existing language with mature tools and libs. Why reinvent everything again? Unless their real intent is to lock you to their own ecosystem and then mildly steer you to using or preferring to integrate with their own products.

BTW: Is dart really open? Publishing sources does not mean a thing, is Google making choices?

<comment><USER32> [https://flutter.io/docs/resources/faq#why-did-flutter- choose...](https://flutter.io/docs/resources/faq#why-did-flutter-choose-to- use-dart)

"Is dart really open? Publishing sources does not mean a thing"

BSD license, ECMA standard.... [https://github.com/thosakwe/xart](https://github.com/thosakwe/xart)

</comment></comment></comment><comment><USER33> I've been using Flutter for a little over a year and I absolutely love it. Hot reloading, Dart tree shaking, Static type checking, etc. What's not to love? Dart widgets are consistent, making UI design easy peasy. UI widgets are definitely skewed to Android (for now), but iOS work is moving quite fast.

Try it, you'll love Dart.

</comment><comment><USER34> I've been following and using Flutter since release 0.2. I think Flutter is an amazing project. It makes writing concise and beautiful apps very easy. I've come to love Dart and the whole Flutter framework. I really think it is the best framework to write Android applications. It also works great for iOS were you can either choose to use Material or Cupertino components. It is a huge improvement over the old Android SDK; which is quite outdated in my opinion. It's too hard to create a beautiful app with the current Android SDK. To many hurdless. Flutter feels like what developing an Android app should be like today. Another thing about Flutter is that it's also ready to work with Google's (upcoming; maybe) Fuchsia OS. One loose end is still the plugins for native features on either iOS and Android. There are many community driven plugins which aren't really maintained. Fortunately there is also a large set of plugins maintained by the Flutter team itself.

I've tried Xamarin, React Native and Cordova (god forbids) and native development on iOS and Android. My preference is Flutter.

I've done one big(ish) project with Flutter and it's called "My Leaf" and it is a third party alternative to the NissanConnect EV app. It's used for controlling the Nissan Leaf and Nissan e-NV200 (both EV's). It's open source and available on Android and iOS;

[https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...](https://play.google.com/store/apps/details?id=dk.kjeldsen.carwingsflutter)

[https://itunes.apple.com/us/app/my-leaf-for-nissan- leaf/id14...](https://itunes.apple.com/us/app/my-leaf-for-nissan- leaf/id1436701776)

I've seen some of the comments in this post talk about developing plugins for Flutter. I actually think it is easy and does not require much boilerplate contrary to what people say. My guess is that they really haven't tried writing a plugin but only peeked at the documentation.

</comment><comment><USER35> Flutter renders the whole UI, like a game engine. In the past, this has meant that if there isn't a Flutter implemention of a component (like a video player or map), you couldn't add it to your app. I don't know if that's still true.

[edit]: It looks like this has been addressed with the PlatformView widget: [https://developers.googleblog.com/2018/12/flutter-10-googles...](https://developers.googleblog.com/2018/12/flutter-10-googles- portable-ui-toolkit.html)

[edit]: Sorry, bluetidepro - this was supposed to be a reply to you.

<comment><USER36> That's modern development for you. Shipping a copy of Skia so you can render exact facsimiles of Android widgets to a Vulkan context and avoid having Android render Android widgets with Skia to a Vulkan context.

A full Chrome copy for your desktop app is whatever, we have the resources, but on smartphones this is actively harmful. It bypasses the hardware compositors. Displaying a video, they have to render that to a graphics texture; on many smartphones, the IP that is doing hardware video decoding has nothing to do with the GPU and they might very well not use the same formats, requiring CPU conversion (if it's at all possible).

<comment><USER37> For bonus points you've probably broken accessibility on many platforms as the way that a11y works is intrinsic to the native widgets used by a platform.

<comment><USER38> I wouldn't assume that. It's literally the number one thing people bring up with custom UI components, I'd be very surprised if Flutter ignored the issue.

<comment><USER39> [https://flutter.io/docs/development/accessibility-and- locali...](https://flutter.io/docs/development/accessibility-and- localization/accessibility)

</comment></comment></comment></comment></comment><comment><USER40> Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make."

The comment from pzo points out an even worst of an adoption showstopper.

<comment><USER41> Here's some of the explanation about why they chose Dart:

> There's a lot of nice properties of Dart, we talk some about this on our > website at our frequently asked questions. One of the nice properties of > Dart is that it has a really fast garbage collector, one of the choices that > we made in Flutter was to have this reactive style system where it's very > common to allocate thousands of objects in a – if not, tens of thousands of > objects in a single frame.

> In a span of a few milliseconds and then immediately let go of those objects > again. There's a variety of ways to do that but Dart, having a generational > garbage collector, can handle large volumes of short lived objects very > quickly. Dart also has some really nice performance characteristics, it has > an ahead of time compiled back end which allows us to compile straight to > native arm code, allow us to achieve really fast startup on really > consistent performance and Dart also has a nice focus on developer > experience which really got along well with my team.

From [https://softwareengineeringdaily.com/2018/07/09/flutter- with...](https://softwareengineeringdaily.com/2018/07/09/flutter-with-eric- seidel/)

<comment><USER40> No one uses Dart. No one is going to switch from React or Vue to Flutter when they can't bring over their TypeScript skills and tooling. It was a stupid, arrogant decision on Google's par, end of story.

<comment><USER42> As someone who use Java a lot and don't favor Javascript I'm grateful there is Dart.

<comment><USER43> Typescript isn't JavaScript

<comment><USER44> In fact, one of the best thing about typescript is that you can bring in almost everything you know about javascript into the game.

It took me few days to pick it up when moving from JS to typescript. I don't get it when people say it is complex or adds complexity.

<comment><USER45> > I don't get it when people say it is complex or adds complexity.

js is the complexity people are worried about. the number 1 reason i'm considering going to flutter over react is having to learn js

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> > One of the challenges that React Native developers face, or have reported in > the past — one challenge is that native React Native code is written in > JavaScript, which means that it's run using the browser's JavaScript engine, > which immediately kind of move this a little bit away from the native model > of the platform.

Calling React Native "not native" while eschewing platform UI widgets is a bit thick. I'd actually of the opinion that React Native is "more native" than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual "native" apps because the React Native team doesn't need to try to emulate system controls.

<comment><USER47> > React Native team doesn't need to try to emulate system controls.

The solutions for push navigation across Android and iOS using React Native were pretty poor and didn't emulate system controls the last time I used them. Has that changed?

<comment><USER46> Not sure. But Flutter can't even get switches and text fields to work right, so it really has much further to go than React Native does.

</comment></comment></comment><comment><USER48> One of the main issue with Flutter is that you can't embed a native view inside a flutter widget tree. This makes it limited as we can't have inline maps or custom video views.

There are people working on it. The progrss has been slow. I checked a couple of weeks ago and the issue was still open.

But as far as I know you can have a native view in its own activity.

Though not a blocker for simple apps which previously used Cordova or ionic, I don't think Flutter is ready to replace native development for immersive apps.

Embedding a native view in cross platform UI is possible with Xamarin and React Native, so they are more practical choice for certain types of apps that need this.

<comment><USER49> I think this is one of the things they announced today, search for "Platform Views": [https://developers.googleblog.com/2018/12/flutter-10-googles...](https://developers.googleblog.com/2018/12/flutter-10-googles- portable-ui-toolkit.html)

</comment></comment><comment><USER50> Google Developers' Blog has just posted an announcement on Flutter 1.0:

[https://developers.googleblog.com/2018/12/flutter-10-googles...](https://developers.googleblog.com/2018/12/flutter-10-googles- portable-ui-toolkit.html)

</comment><comment><AUTHOR> Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter.

Will Google really support all three over the long term?

<comment><USER35> If you consider APIs that power its businesses, Google's support history is a lot better. Dart and Closure were never popular outside Google, but they're still invested in because they are used internally.

Android and Chrome are both heavily invested in by Google, with massive external ecosystems too. Speaking in a personal capacity with no insider knowledge, I'd be shocked if Google stopped supporting either.

The UI for Fuchsia is written in Flutter, so it's got a pretty big internal customer too: [https://fuchsia.googlesource.com/topaz/+/HEAD/shell/](https://fuchsia.googlesource.com/topaz/+/HEAD/shell/)

<comment><USER51> You mean the OS that is developed independently from Android with completely separate teams and that nobody knows where it will be in 2 years ?

Since this is Google we are talking about, no warranty that this will ever go on one of their flagship phones.

<comment><USER52> That's just a senior dev retention project.

<comment><USER53> Or maybe not, and that's Android vNext.

</comment></comment></comment></comment></comment><comment><USER50> The widget layer of flutter is Skia which is written in C++ and Flutter apps compile to ARM binary (native) code. Someone else asked about whether a Flutter app can be ported to Linux; why not compile both the logic and the UI directly to WebAssembly?

<comment> forgot-my-pw There's Flutter desktop: [https://github.com/google/flutter-desktop- embedding](https://github.com/google/flutter-desktop-embedding)

And web: [https://medium.com/flutter-io/hummingbird-building- flutter-f...](https://medium.com/flutter-io/hummingbird-building-flutter-for- the-web-e687c2a023a8)

<comment><USER54> Holy smokes! That's awesome! (I was aware of the desktop embedding, but also on the web... that's really cool)

</comment></comment></comment><comment><USER55> Platform views and especially Hummingbird are huge announcements. Wish the OP linked to the dev blog instead:

[https://developers.googleblog.com/2018/12/flutter-10-googles...](https://developers.googleblog.com/2018/12/flutter-10-googles- portable-ui-toolkit.html)

</comment><comment><USER56> Live stream at [https://youtu.be/NQ5HVyqg1Qc](https://youtu.be/NQ5HVyqg1Qc)

</comment><comment><USER57> Looks cool but not too much of cross-platform - iOS and Android only. It seems the only really cross-platform GUI technologies still are browser-powered and Qt.

<comment><USER58> iOS, Android, and Fuscia. I just found out that there is now Hummingbird for web as well.

<comment><USER59> Does Fuchsia use the Material renderer, like Android?

</comment></comment></comment><comment><USER60> I did a small app in flutter last week out of curiosity (fetching rss/atom feeds, rendering html content) and was surprised how easy it was to work with tooling that flutter provides. Also was pleasant surprised on how well Dart fits in to this use case. Go flutter!

</comment><comment><USER61> Congrats on their 1.0 launch! I haven't looked too closely at Flutter yet, to be honest. How does it compare to React Native (besides what a basic Google search will yield)? Has anyone jumped ship for either or after trying one of them?

<comment><AUTHOR> Comparison: React Native (and Xamarin, for that matter) use platform-native widgets with JavaScript composing the UI dynamically in the case of React Native (and UI's either dynamically composed or statically compiled with Xamarin -- depends how you build the app). Flutter brings it's own widget layer to iOS and Android (and Fuchsia?) so it's more like starting with a blank 2D graphics canvas and creating your own controls. Advantages: since this rendering layer and widgets are compiled from C++ the performance is excellent. Disadvantage: if you want a widget that isn't in the current set of controls and your C++ skills aren't up to the task, you'll be left wanting to do things you cannot. Not sure what scenarios are affected by this but it's something to keep in mind.

<comment><USER62> The widgets are written in Dart, not C++. If you need a new widget, you would write it in Dart, which is the same as the application language. This contrasts with React Native, where new widgets/views would be written natively and wrapped in React Native.

<comment><USER63> I'm going to be a little bit pedantic, but that's untrue. On React (DOM, Native…) you create your widgets with React, and compose them as components.

If you need to go deeper (for some specific perf issue, usually for animation stuff) then you go native. But it's a second class approach — well, it has first class support and is not as "second class" as it is for example in Titanium or "completely out of scope" in Cordova.

</comment></comment></comment></comment><comment><USER64> For those who don't know: The app on the first screenshot is inkino [1] which had two Show HN in the past months:

\- [https://news.ycombinator.com/item?id=16818170](https://news.ycombinator.com/item?id=16818170) (42 comments)

\- [https://news.ycombinator.com/item?id=18399542](https://news.ycombinator.com/item?id=18399542) (version 2.0, 2 comments)

[1]: [https://github.com/roughike/inKino](https://github.com/roughike/inKino)

</comment><comment><USER26> Would love to see something like this extended to the Linux desktop.

<comment><USER65> This is what the flutter-desktop-embedding [0] project is trying to address.

[0] [https://github.com/google/flutter-desktop- embedding](https://github.com/google/flutter-desktop-embedding)

</comment></comment><comment><USER66> Damn - that VSCode theme and color scheme from the screenshot in the article looks really nice.

Does anyone know its name?

1: [https://techcrunch.com/wp-content/uploads/2018/12/pasted- ima...](https://techcrunch.com/wp-content/uploads/2018/12/pasted-image-0.png)

<comment><USER67> Pretty sure that's the Nord theme([https://github.com/arcticicestudio/nord- visual-studio-code](https://github.com/arcticicestudio/nord-visual-studio- code)).

<comment><USER68> Perhaps paired with [https://marketplace.visualstudio.com/items?itemName=Coenraad...](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket- pair-colorizer) ?

</comment></comment></comment><comment><USER69> Oh man, if this could get things like Signal Desktop off of Electron, I would be so happy...

</comment><comment><USER70> Would like to use it for a Linux app. Looking forward to when that has first class support.

<comment><AUTHOR> The widget layer is written in C++ (Skia). There's no reason the Flutter toolkit couldn't be quickly adapted to Linux. Or FreeBSD. Or Windows, macOS, OS/2 or even Windows Mobile.

<comment><USER71> It does currently work on Linux, although fairly barebones. You can Google "Fluttet desktop"

</comment></comment></comment><comment><USER72> I'm currently using it as an hobby for creating simple UIs. It's actually pretty easy, and it feels more like a newer QML kind-of language. And I like Dart's syntax, coming from a C/Java world.

</comment><comment><USER73> Seemed like a lot of the app highlights in the highlight real video had jank, either when scrolling through a list of images or animating card swiping. Anyone have insight as to why?

</comment><comment><USER74> Does anyone have a feel for how good flutter's documentation for canonical approaches to common use cases are now? The last time I tried it, even a simple task like changing the UI when returning from a login screen was unknown territory for many developers. The examples in the documentation were all for single screen simple apps. Has this changed? Or is the community still trying to figure out best practices?

<comment><USER45> flutter's community feels like Xamarin's community - people who are already well versed in both android and ios development looking for a common codebase solution. very much lacking in the documentation section in terms of how you get from A to Z. everything is "Z can be implemented this way" w/o any discussion of how to use it in alternate ways(like how the android and ios dev documentation is structured) i'm gonna jump in coz it seems interesting but i'm super afraid of the iOS painpoints i'm going to hit(I have no knowledge of iOS development just android)

</comment></comment><comment><USER75> I don't understand why Apple is the only one left that uses a strongly typed pre-compiled native programming language. It really isn't hard to use Swift compared to other programming languages. And it's a really nice to use, safe and if you want it to be also a language that allows you to write really fast algorithms.

<comment><USER76> Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift. Flutter also provides a first class Reactive UI story: something sorely lacking in native iOS (or Mac) development.

PS Java (or Kotlin) are AOT compiled in all recent versions of Android.

<comment><USER75> > Dart is strongly typed and pre-compiled, at least when packaged. It can run > in interpreted mode in development for live/hot reload: a major advantage > over Swift.

Ah, that's how they do it. That's neat! But the language still has to deal with JavaScript compatibility.

> PS Java (or Kotlin) are AOT compiled in all recent versions of Android.

But it's still a mess to call native code. And still has Java garbage collection.

</comment></comment></comment><comment><USER77> Having using Flutter since the alpha releases, it's great to see how the framework has evolved to a production-ready release. Honestly, learning Dart isn't that difficult nor foreign if you're coming from a low-level language such as C#/C++/C or Java. Been enjoying using it since.

</comment><comment><USER78> Looks nice. I find it similar to Adobe AIR but with DART as programming language.

<comment><USER79> Except Adobe Air doesn't compile to native and the apps don't run until you nag the user to download the Air runtime.

<comment><USER9> I guess someone is very outdated on their information.

[https://www.adobe.com/devnet/air/articles/aot-or- interpreter...](https://www.adobe.com/devnet/air/articles/aot-or- interpreter.html)

Air supports native compilation since 2012!

<comment><USER79> I'm not sure why you'd be referring to me in the third person while replying to me, but if that's the case then yes, it's quite possible they've improved.

> SWF content on all platforms other than iOS is JIT compiled

Cool, but I use Android.

</comment></comment></comment></comment><comment><USER80> It is the latest crush of every developer. Learn what are the top features of this new app framework: [http://soo.gd/UbXY](http://soo.gd/UbXY)

</comment><comment><USER81> Flutter looks cool. Dart needs more of an ecosystem though. I was trying to play with flutter last week, gave up when I discovered there is no standard lib FFT implementation in Dart.

<comment><USER82> [https://pub.dartlang.org/packages/fft](https://pub.dartlang.org/packages/fft)

<comment><USER81> Yeah I saw that. It's just maintained by some random guy. Which is great and all, but something like fft should really be part of the standard lib.

<comment><USER82> I disagree. Something rarely needed like FFT should not be included in any stdlib. Keeping it out too allows better control and more frequent releases.

</comment></comment></comment></comment><comment><USER83> How does it handle integration with maps libraries (e.g. Google Maps) and BLE support?

Anyone has any experience with how well those work with React Native, and could share their experiences?

<comment><USER56> They shown the integration today. Its so cool you would be blown away if you saw that history of everything app demo. I am not able to find the demo app. Its in the live stream.

</comment></comment><comment><USER84> How does flutter handle BLE/WiFi communication to hardware, rendering graphs, NFC, device sensors? Any comments on the experience? Do you recommend it?

<comment><USER85> Don't think there are builtins for that, Flutter is more focused on drawing UI. For functions like these it usually just makes sense to call the native APIs over a bridge (there's a bridging mechanism included in Flutter - <USER2> pass messages over channels to and from the native code).

</comment></comment><comment><USER86> Does Flutter have easy modules for standard things like login, comments, payments etc. or does that involve writing separate server side code?

<comment><USER55> Combined with Firebase, yes, that's fairly easy to setup.

[https://firebaseopensource.com/projects/flutter/plugins/](https://firebaseopensource.com/projects/flutter/plugins/)

<comment><USER86> This is great. Thanks!

<comment><USER55> NP!

</comment></comment></comment></comment><comment><USER87> This looks really cool!

Could someone explain the difference between Kotlin and Flutter given that they are both being pushed for app development now?

<comment><USER88> I haven't used either, but Kotlin is a programming language you can use on Android -- it's essentially another JVM language as an alternative to Java -- whereas Flutter is a UI toolkit you can use on multiple platforms (mobile and desktop), think of it as analogous to Qt.

<comment><USER87> Ahhh. That makes sense! Thank you. I was scratching my head about it, but I guess I just need to read more now.

</comment></comment></comment><comment><USER89> It's sad that this thought had to cross my mind, but how long until Apple prohibits or penalizes the use of this toolkit?

<comment><USER46> Why would they? I don't see any guidelines it violates, other than the loose suggestion to have your app be reasonably designed.

<comment><USER89> > Why would they?

For reasons of business strategy. With this toolkit, the AppStore might lose its exclusivity on a lot of apps.

Exactly what Google wants, and Apple does not want.

<comment><USER90> If they did that they would also have to ban games that use game engines such as Unity, because they're doing the same thing as Flutter.

</comment></comment></comment></comment><comment><USER91> Does flutter have an official bluetooth/BLE library? I would have expected that to be in place before a 1.0 release.

</comment><comment><USER92> Why is this any better than React and React native? Why would I want to learn Dart and this ecosystem?

I mean, it better be damn good

<comment><USER93> Flutter is supposed to be much faster than React Native because of Skia engine and its GPU acceleration and AOT compilation.

<comment><USER92> What's "so much faster" and should anyone care unless they're making games?

Why isn't there an equivalent of Interface Builder for React Components?

</comment></comment></comment><comment><USER94> I'm surprised to see them showing Taobao app there. I know it is done in Weex, without anything like Flutter.

</comment><comment><USER95> How does Flutter go with mapping apps, location etc? is there good integration or SDK's?

</comment><comment><USER96> What about a WASM powered UI kit? Wouldn't that finally fix the cross language issue?

<comment><USER97> If you're looking for a wasm-enabled toolchain that runs native apps in a similar way you should check out nativescript[0], I don't think they support it yet (?) but that's definitely where it would land first.

Another example of where they follow standards/stick to browser specs is their use of web workers for background tasks [1]. In comparison Flutter uses dart isolates[2] which makes sense of course, since they use Dart -- similar performance models (do hard stuff in another thread).

[0]: [https://www.nativescript.org/](https://www.nativescript.org/)

[1]: [https://www.nativescript.org/blog/using-workers-in- nativescr...](https://www.nativescript.org/blog/using-workers-in-nativescript- to-execute-javascript-on-background-threads)

[2]: [https://api.dartlang.org/stable/2.0.0/dart- isolate/Isolate-c...](https://api.dartlang.org/stable/2.0.0/dart- isolate/Isolate-class.html)

</comment></comment><comment><USER98> For people that have used Flutter to make any app: how much memory is used at runtime?

</comment><comment><USER99> Any news on if the desktop embeddings will become a supported part of Flutter?

<comment><USER100> in today's keynote, google announced that you'll eventually be able to use one dart/flutter codebase for ios, android, mac, windows, linux, and the web. you can't get much more cross-platform than that.

<comment><USER99> I am aware that you can build one codebase for all those platforms, the question is whether all those platforms are supported. In particular [https://github.com/google/flutter-desktop- embedding](https://github.com/google/flutter-desktop-embedding) still says that desktop use of flutter is unsupported.

DISCLAIMER: Opinions expressed are my own and do not reflect my employers views.

<comment><USER100> ios and android are currently well supported. the rest are somewhere off in the future.

in the google keynote today, they revealed that the app they were using for showing slides was a flutter app running on a mac.

</comment></comment></comment></comment><comment><USER101> Can you target web with it?

<comment><USER102> They previewed Project Hummingbird to do just that:

[https://techcrunch.com/2018/12/04/googles-flutter-toolkit- go...](https://techcrunch.com/2018/12/04/googles-flutter-toolkit-goes-beyond- mobile-with-project-hummingbird/)

</comment></comment><comment><USER103> Flutter needs to add support for xml styled declarations and Swift

<comment><USER104> No it does not!

</comment></comment><comment><USER105> Does this allow hot code-push updates like React Native does?

</comment><comment><USER103> Flutter needs jsx / xml like declarative support

</comment><comment><USER106> Looks great!

</comment><comment><USER107> Nothing will make me learn or do Dart.

<comment><USER108> Well, you're lucky. There is React-Native (JS/TS), Xamarin (C#) and Boden (C++)

</comment></comment><comment><USER109> I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again.

Why can't this domain be smarter like Compiler world and build pluggable components? So something like, a react-engine that renders the recently changed display node. The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works with GUI nodes of native GUI toolkit.

So now going from each OS to another, you don't have to learn gazillion different ways to specify the layout. The type of nodes displayed on your GUI app changes from each environment to another. So you get to have the same programming techniques and you can get a web-app or a desktop app.

<comment><USER110> It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon).

It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mess.

There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.

<comment><USER109> Thanks for your reply - it was a pretty insightful rebuttal.

Do you think in the future it might be possible for say Flutter to:

1\. Refactor flutter into a layout engine and gui widgets

2\. Provide the layout engine as an interface on all desktop OSes. Something like a standardized syscall like interface.

3\. Anyone can implement a new GUI toolkit to this layout engine interface.

4\. For desktop OSes, the number of styling options is less than full blown CSS capabilities(in HTML dom) and these options get compiled out, making execution of native apps GUI slightly faster than DOM apps. Basically, desktop GUI styling is a subset of DOM CSS styling.

5\. We use a JSX like templating language to specify UI that either gets compiled to HTML or generates native GUI widgets.

Not sure all of my thoughts are 100% fleshed out but does this sound feasible in future?

<comment><USER111> I like the sound of orthogonal components.

</comment></comment></comment></comment><comment><USER43> google have, from a game theory perspective, made it harder and harder for me to support their products until they become established.

not investing my time or effort into anything google has done until i know it wont be wasted.

</comment><comment><USER9> Unless they force Flutter upon Android devs, I will let it pass, not eager to learn Dart.

<comment><USER112> It's strange to me that after all this time, every time a thread about Flutter reaches Hn or proggit, there are multiple comments about the choice of the Dart language.

I think they've made it pretty clear by now that they don't have intentions of switching from Dart. Heck, they've published an entire "Why Flutter uses Dart" article explaining their reasoning.

It's like beating a dead horse.

Besides, you could always just not use Flutter if you dislike it that much.

<comment><USER9> Their whole reasoning just feels like justification after fact. specially when one has experience with older development environments which offered similar developer workflows.

I guarantee to you that if they had choosen a proper modern language, Flutter's uptake would be much higher.

As it is, you will see many of us complain about Dart until Flutter ends up being replaced by something else, unless they force Android developers to actually use it.

<comment><USER90> Then why bother to post to complain? Is it necessary to also post in React Native threads about how that framework does not fit your needs?

<comment><USER9> Because Flutter would be a nice framework to use if they hadn't decide to bet on a language struggling for survival outside Googleplex.

React Native uses a programming language widely accepted, no need for complains.

<comment><USER39> You said you can't be bothered to learn dart because you want to build your skills in c# etc. As a result the only criticisms you can make are devoid of content: It's not a proper, modern language (what?). It's struggling for survival...

<comment><USER9> I can't be bothered to learn Dart because it lacks market value.

C# was just an example of a language that is actually worthwhile to have on a CV. I could have given many other examples.

Ad Words team rescued Dart from certain death and Flutter it is attempt to come play into the ring.

</comment></comment></comment></comment></comment></comment></comment><comment><USER113> Meh, Dart. Yet another language to master, that does not bring me any advantages overall, except for this very platform.

I also would welcome an XML based, declarative approach to GUI. Makes cross- platform development even more easy.

<comment><USER114> +1 for XML/declarative. One day :(

<comment><USER113> You still have hope?

Somehow I find it hard not to believe, that XML won't come back. One day :(

</comment></comment></comment><comment><USER115> Google is spending so much money on Flutter , it's insulting.

Honestly, the entire industry is shifting towards JavaScript/Typescript and the only language that they could think of for Flutter is Dart ?

This is even more Hypocrite knowing that Flutter doesn't actually run the Dart VM, it uses AOT and compile to native code.

Meaning we could use literally any ECMAScript language to run with Flutter instead of Dart.

There is nothing that Dart does that justify the choice of this language.

<comment><USER116> I'm not a fan of Dart either, but common JavaScript/TypeScript isn't exactly the holy grail either. JS is basically unusable due to, well lack of types, and TypeScript hacks them into it by hugely increasing complexity of everything.

Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.

<comment><USER117> Or Swift

<comment><USER118> That would turn a lot heads!

</comment></comment></comment></comment><comment><USER114> DOA. Bad performance, weird language. It'll never be popular enough to justify learning. Sad to see such a waste of developer time and effort.

<comment><USER90> Less space than a Nomad.</comment></comment>


Are You an Aspie? Take the Test! - <AUTHOR> http://www.rdos.net/eng/Aspie-quiz.php Find out to be better prepared for discussions like this http://news.ycombinator.com/item?id=658774 <comment><USER2> Not my primary account. I got a score of 140. Any suggestions on what I should do?</comment>


How Multiple Payment Methods Help Increase Conversions - <AUTHOR> https://blog.paymill.com/payment-methods-conversions/

<comment><USER2> cool insights. good read.

</comment><comment><USER3> Great stuff</comment>


File Versioning, Caching & Hashing - <AUTHOR> http://www.natabbotts.com/article/file-versioning-caching-and-hashing

<comment><USER2> Interesting, and very close to the implementation of Etags.

On the upside, it means that files that haven't been changed won't ever be rerequested without needing a round trip to the remote server.

On the downside, you clutter up caches with "dead" but not yet expired files, and you have to deal with scripts every time you change files, which is likely to decrease the reliability of your site and provide a new point of failure.</comment>


Home - Chrome OS - <AUTHOR> http://www.google.com/chromeos/ <comment><USER2> "Nothing but the web"?

 _"Nothing but the web"_??

How can you be so tantalizingly close to such a glorious tagline as " _Nothing but net_ " and not use it?

AAAAAAAAAAAAA!!!!

<comment><USER3> I saw "Nothing but net" used as a slogan for a dialup Internet product in _1995_. It was a little too precious, even fifteen years ago.

<comment><USER4> That's even worse than the AOL demo CDs I got which said, in enormous letters, "56K TURBO!"

Has our collective taste improved since then? It often seems that way.

</comment></comment></comment><comment><USER5> Wow, the pilot program applications are significantly different depending on where you're coming from.

This is the form linked from the above site: <https://services.google.com/fb/forms/cr48advanced/>

And the form linked from within Chrome's new tab page: <https://services.google.com/fb/forms/cr48basic/>

Edit: Also amusing, one of the options for "Which program do you use to listen to music most often?" is "Dude with a guitar on the corner."

<comment><USER6> I think they may have messed up a bit on the pilot application; I applied using the long form, but it forced me into choosing a State (list of 50 USA states) even though I selected my country to Canada. I understand that they only want US residents right now (Verizon-tied), but as a web form it doesn't make any sense.

We'll see what happens. :)

<comment><USER7> I thought the same thing - and then read the fine print:

> I understand that Google will only ship the device to a US-based address and > cannot send this device to a P.O. Box or address outside of the US.

</comment></comment></comment><comment><USER8> The most interesting page to me is this one:

[http://www.google.com/chromeos/pilot-program- forbusiness.htm...](http://www.google.com/chromeos/pilot-program- forbusiness.html)

I think Google is far more ambitious in the business space than most people realize. They are aiming directly at Microsoft's empire. Consider the amazing TCO for a business that deploys only Google Apps and ChromeOS notebooks to its employees. Obviously, Google Apps are not quite good enough yet, but Google knows this is a long term project. The apps are constantly improving and at the same time people are steadily migrating to the web for many of their workflows anyway. At some point it'll get really hard to justify spending $1-2k up front plus IT overheads per employee when you could get it for virtually nothing with a ChromeOS notebook.

</comment><comment><USER9> Irony: clicking on the "Chromium and Open Source" link gives you a "you must upgrade your Adobe Flash plugin" message.

Oops.

</comment><comment><USER10> I really want to try one of these, but I can't lie to Google. I don't use the Web for anything. I listen to music with xmms2 on the command-line. I write in Emacs. I read my email in Emacs. I download TV shows from Usenet.

I realized that Emacs is the Chrome OS, except with 25 years of libraries and applications to show for it.

<comment><USER11> For someone with 23544 karma, I think you use the web quite a bit, even if it's from within Emacs.

<comment><USER10> No, it means I submit comments to Hacker News :)

I use the web for visiting websites, but that's only a very small part of my day. Most everything I do for fun or socialization or for creative purposes I do without the web. I may publish my stuff to the web, but it's a _medium_ , not a _tool_. A painter wouldn't say he spends a lot of time working with magazines, even if most people know his paintings from one.

Anyway, I'm not criticizing the idea of Chrome OS. Like I said, Chrome is basically a pretty Emacs, which is a great environment. But it won't work for me today.

(Would I buy a Chrome OS _tablet_ , just for reading random crap on the web? You bet! But I wouldn't commit to using one as my primary computer, because I wouldn't be able to do anything I want to do.)

</comment></comment></comment><comment><USER12> That was a great idea to put a "search" key in place of a caps lock key. I search all the time, and haven't (intentionally) used caps lock once my entire life.

<comment><USER13> How do you type acronyms like NASA?

<comment><USER6> It's faster to hold shift. Caps Lock + n + a + s + a + Caps Lock is 6 keys, vs Shift + n + a + s + a is only 5 keys.

<comment><USER13> But I use both fingers for the letters in NASA so I would normally have to hold 2 different shift keys. Are you saying you hold just one shift and type the rest of the letters with your other hand

<comment><USER14> Hold left shift with left pinky. Type n-a-s-a with both hands. I honestly have no idea how else you would do it. Hitting caps lock seems like such a waste of time.

<comment><USER13> How is it a waste of time when caps lock is as close to my little finger as shift is and I can type normally for those few letters?

<comment><USER15> Because you have to press it twice. I tried both and shift was definitely easier.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I have no idea whats the big deal about Chrome OS. Didn't a lot of OEM's already have this kind of functionality?

Atleast my 1.5 yr old Sony VAIO has a Web button, which boots the system to slightly stripped down version of Firefox without booting OS. Its also very fast, boots in 10-20 seconds and runs flash content too.

<comment><USER17> There is business strategy involved as well. Google wants to reduce its dependency on Apple and Microsoft. Unless you were a GNU+Linux/BSD enthusiast, you were accessing their products from a laptop running the software of one their competitors. Similarly, this is one of the reasons for Android. They could have just made apps for the iPhone, Windows phone, RIM, etc, but they made apps for the iPhone and Android to help reduce the dependency and give themselves more freedom

<comment><USER18> .. then why didn't they give us a free OS X instead of a locked down platform?

<comment><USER17> ...because that would still tie them to Apple.

</comment></comment></comment></comment><comment><USER19> I run Windows 7 Ultimate on a $219 Aspire One that I added a decent 60GB SSD to ($100) and an extra 9 cell battery $59. Between both batteries, I have enough charge to last my from Barcelona to San Francisco with a 4 hour layover at JFK. And, I have a full web experience, any files I need are perfectly synced without any hassle via Dropbox. And, I can use most any desktop software I like.

3G service from most any carrier that I've tried is barely adequate for surfing the web on my Android cell phone. I would hate to have to rely on 3G service for all external storage for my computer.

I don't see how eliminating local storage on my computer and putting all my data on Google's servers is better than having access to that data locally. Random access to an SSD is 10^(3-4) ns, a random seek on disks with spindles is 10^(6-7)ns and a packet sent round trip across the country is 10^(8-9)ns.

I can buy a 16GB flash drive at Frys for $15. When local storage is so ubiquitous and cheap, I don't understand why would you want to develop an OS that relied on packet transfer for permanent storage rather than local storage with delayed synchronization.

It's not like having local permanent storage is much of a hindrance. I've never said, "Damn, if I could only get rid of 60GB of local storage on my computer, every thing would be great". I do find myself cursing my lack of network coverage on a regular basis, however.

I suppose that it makes sense if you are Google and you want as much of people's data on your servers so you can money by mining that data. Aside from that, I just don't get it.

<comment><USER20> Doesn't it have an offline mode? I'd expect there tobe one, with syncing to the cloud behind the scenes.

</comment></comment><comment><USER21> _It runs web-based applications, not legacy PC software_

When did PC software become legacy?

<comment><USER22> My experience is that "legacy" refers to "any software that we want to put down or don't want to support 100% any more", so I guess Google decided all native software was legacy the minute they announced Chrome OS.

I've seen the same thing happen with code internally - a developer writes an untested replacement for a component and then instantly declares the old version "legacy", even though it still works fine.

<comment><USER23> It could be worse...

"Netscape will soon reduce Windows to a poorly debugged set of device drivers." — Marc Andreessen (1995)

</comment></comment></comment><comment><USER24> What a poor survey. These notes are about the Developer version.

The final question is, "If selected, will you use this Chrome notebook as your primary computer and provide regular feedback?" This should have been the first question so people didn't have to waste their time filling out the survey if they won't use the machine as their #1 machine.

How many developers would use a Chrome OS netbook as their primary computer? A secondary computer (think tablet) sure, but for doing their day-to-day coding?

I've used a tiny Viao (pre-netbook era) as a main (home) development machine, but that had a full Linux OS and was unusual.

Other issues:

\- Have to provide a US state even for people outside of the US

\- Item labeled "Primary Email" with a note, "If you have a Gmail address, please supply that."

\- Can only answer once to, "Which OS do you use most of the time?" (How about people who use two OSes equally?)

\- Similar problem for, "Which web browser do you use most of the time?". (Different browsers on different computers? Using multiple main browers at the same time?)

\- "What type of device do you use most frequently?" Again, only one answer. (I use laptop, desktop and ipad extensively)

\- "How do you check your email most often?" single option. (How about people who, you know, check both work and personal email?)

\- "Which apps or tools do you use at least once a week?". It names specific applications. Hard to tell if "Adobe Reader" is meant as a proxy for "PDF Viewer" or not.

\- "How do you connect to the Internet most often?" only a single answer...

\- (snip: other questions with only single answers that should allow multiple)

<comment><USER25> > How many developers would use a Chrome OS netbook as their primary computer?

Boom, right here. That said, they might send you one even if you don't use it as the #1.

Also, I think your form was borked. There were several things you encountered that I didn't.

</comment></comment><comment><USER26> So... Google has two OSes now, Android and ChromeOS. One is for mobiles and pads, one is for.. what?

<comment><USER6> Computers. You know, the ones with keyboards and mice.

<comment><USER27> That's the part that confuses me. Computers are traditionally more powerful and flexible than SmartPhones / tablets but a computer running ChromeOS is actually more limited than an iOS or Android device at this point.

<comment><USER28> Most computer users are not powerusers and they don't need a powerful PC or OS. Current operating systems are over complicated for casual users and limitations work as an advantage for people like my parents. They shouldn't need to understand what a file system is, everything should just work in the background.

</comment></comment></comment></comment><comment><USER29> "Waitlessness means never having to wait for the the web. "

Seriously, Google?

</comment><comment><USER30> So is there any concept of "files" and/or "folders" on the hard drive of these computers? If so, is there a file explorer app to manage them? Or is it black- boxed, like an iP(hone|ad|od)?

</comment><comment><USER31> The Pilot program is open to individuals, businesses, schools, non-profits and developers based in the United States.

Sad faces for people in the UK.

</comment><comment><USER32> OT but nice minimalist design.

<comment><USER33> Excuse me, but what is OT?

<comment><USER34> Off topic

</comment></comment></comment><comment><USER35> Chrome OS is just another step in the division of labor. Instead of managing our data ourselves, it pushes us even further than most other products so far to let others take care of it for us. It'll be there when we want it, and probably better organized, too.

And, for a lot of people, security is a concern, but in the background. A fly buzzing by the screen door, but not something that would keep them from taking an easy option from a company that 'knows the answer to everything'.

So, for most people, what's not to like?

</comment><comment><USER36> Anyone know why they switched the shortcut for "view shortcuts" from the Gmail/ Google Reader "?" button (shift+/) to "Ctrl+Alt+/"? Seems strange to me, as "?" makes intuitive sense and adding a modifier key (like ctrl) would be sufficient to distinguish between shortcuts in Gmail and those in the OS.

<comment><USER37> Ctrl-? opens the help application. We had to add another modifier for the shortcuts.

<comment><USER36> Makes sense. Thanks.

</comment></comment></comment><comment><USER38> US only :(

<comment><USER39> I've tried applying from Poland without any error messages appearing at least.

It's rather confusing though; why have a country drop-down if it's only open to US residents?

<comment><USER7> My guess is that they'll use it to gather demographics of people interested in the device. There was a ton of information to fill in that I'm sure any marketer would love to have.

</comment></comment></comment><comment> mike-cardwell It just looks like a web browser. I thought Chrome OS was going to be a nice user interface which had websites appear like native apps. Instead, it's just a web browser. Not impressed at all. I expected more.

<comment><USER40> Could you be a bit more specific about what you were expecting? Did you think they could make it magically shoehorn web apps into a desktop metaphor? What more does it need than just a web browser, given that the whole point of Chrome OS is to be just a web browser?

<comment><USER41> It's a fair criticism. If the OS is a web browser, why use tabs? They just steal valuable screen real estate. Replace them with a windowing system where each page/app gets its own resizeable window, and you can reclaim some of the virtues of a desktop metaphor.

<comment><USER40> Are overlapping or tiled windows really that useful for web apps being squeezed in to a low-end 12" laptop screen?

They've got a system for chat windows and notifications to show up on top of the main window, and they've got a full-screen button to hide all the window decorations. The only real use a more complex window manager would have is enabling you to show two documents side by side, but I doubt that the horizontal screen resolution is high enough for that to work with most web apps.

<comment> mike-cardwell I do think that overlapping and tiled windows are very useful for a 12" screen. They're certainly highly useful and desirable on my 13" Macbook screen.

<comment><USER40> But how many web apps (or any web sites) are actually useful when reduced to a width of 640px? Almost everything on the web these days is designed for a width that's far more than half of the 1280px that is the widest reasonable estimate for the Cr-48's screen. I've measured GMail, Picasa, and Google Docs as needing 795px, 813px, and 889px, respectively, and Pandora with its ads wants a window more than 1000px wide. If Google's going to show off side-by- side multitasking on a ChromeOS notebook, they'll have to use somebody else's web apps.

If "the cloud" starts to tread on more serious territory and people reach the point where they're willing an able to do things on the web that they would previously use a $1000+ computer for, then Google will have to revisit Chrome OS's basic paradigm. But until then, the main purpose for Chrome OS is to make a true netbook.

</comment></comment></comment></comment></comment></comment><comment><USER42> Looks like it's for US only, but the form allows me to change to another country. Any idea why?

<comment><USER37> Pilot selection is US only _for now_.

</comment></comment><comment><USER43> Oh wow, nice design - I hope they start selling those. Shame the pilot is US only :-(

</comment><comment><USER44> >"Base Bamp"

Check, wait, no, uncheck.

</comment><comment><USER45> Chrome OS: The Closing of Open.

</comment><comment><USER46> Are Chrome tablets coming out?

<comment><USER5> Not in the near term. During the Q&A, several questions were asked about tablets, including how the rise of iOS and Android tablets have affected the team's conception of what an ideal device would look like.

In all instances, the ChromeOS team members reiterated that from the very first day, their vision was to address the notebook form factor, because they're attempting to build a platform that can be used as their own primary device.

</comment></comment><comment><USER47> Free Laptop will arrive, when my free google TV arrives.

How else can you get people to fill out a survey?</comment>


Intro to Congestion Control - <AUTHOR> http://squidarth.com/rc/programming/networking/2018/07/18/intro-congestion.html <comment><USER2> I deployed a custom implementation of IETF BBR on FreeBSD at one of the major CDNs, Limelight, that was wildly successful for the company. One bit of wisdom I will share after having worked in this space for a few years, depending on what you're optimizing for, it's pretty easy to out-muscle the competition and make a "better" CC for your own selfish purposes at a small or large scale.

The real challenge in this space is balancing flow fairness, link utilization, buffering delay, heuristics or models to differentiate congestion from unrelated signals like RF interference causing channel loss, and making the whole thing computationally inexpensive. It's further difficult because the internet is a free for all, in a closed network flow control between each hop would make congestion control unnecessary as you could use a congestion avoidance algorithm instead. Fibre channel is an example of that in wide use with its credit based flows.

</comment><comment><USER3> I've been meaning to do a similar blog post for my hobbyist TCP stack, but this here does explain it more concisely than I could.</comment>


Laptop Ban a Reaction to X-Ray Equipment Stolen by ISIS - <AUTHOR> https://professional-troublemaker.com/2017/05/22/exclusive-laptop-ban-reaction-to-x-ray-equipment-stolen-by-isis/ <comment><USER2> The secrecy issue has gotten out of hand.

The classic military view of secrecy is time-limited. "Where the ship was last week is unclassified. Where the ship was yesterday is confidential. Where the ship is now is secret. Where the ship will be tomorrow is top secret." The opposition will eventually find out what you're planning on doing. The goal is for them to find out the hard way, when incoming fire starts hitting them.

The intelligence community has a longer-term view. "We know, and they know. We think they don't know that we know they know. We hope they don't know how we found out that they know." This protection of sources mindset leads to things being kept secret long after all involved parties know.

The anti-terrrorism community has adopted the intelligence community mindset. This is a problem.

<comment><USER3> This is wrong.

The classification level of information is determined by confidentiality of the information's source. This is done to protect deeply embedded or highly technical means of information gathering.

For example, information that could have only come from the second in command of some organization would require the highest of security classifications whereas information that could have come from any dozens of members of that organization would only require a confidential or secret classification.

Information is required to be classified at the lowest possible level, a guideline that is both taught and enforced throughout most if not all of the Intelligence Community.

source: I was an intelligence analyst for 6+ years.

<comment><AUTHOR> It is certainly correct that DHS, and to some extent our government generally, is known for over-classifying things either out of laziness, desire to avoid embarrassment, or because they believe that anything remotely security related needs to be hidden. As an intelligence analyst, you likely didn't see the misclassified things (I'd imagine roughly everything you did was classified for good reason). It's the political officials who are more likely to over- classify.

<comment><USER3> That's a fair accusation - you're responsible for increasing the classification of material if you find it to be under-classified, or request a review in the opposite case. So, it wouldn't be surprising if something came across the desk of a decision-maker or the IC's version of middle-management and they selfishly raised its classification hoping it'd be lost in a blackhole for fear of embarrassment, etc.

</comment></comment></comment></comment><comment><USER4> >So why was the stolen x-ray equipment kept a secret? I asked my source if there was some security reason for keeping the stolen x-ray equipment from the public, and was told, unequivocally, no. "It's because the mom from the midwest planning to fly her kids to Disney would freak out. They are worried that people would stop flying if they knew."

Kind of ironic, because I've already stopped flying - not because I'm afraid, but because these sorts of measures have gotten to the point where traveling through an airport is an awful experience that I actively avoid.

If I absolutely must travel, I take a train or drive. The only reason I ever fly is if I have to cross an ocean or if I face an emergency that requires me to be present somewhere far away, very quickly.

And in the case of an ocean, honestly, renting a stateroom on a cargo ship seems like a very relaxing way to go if you have the time. I've got a HUGE backlog of books and games and writing and projects to design and you get the idea.

<comment><USER5> "If I absolutely must travel, I take a train or drive. "

The problem with train is it is expensive and time consuming in the States. I could take a train from Chicago to Orlando and it would take around 30 hours and cost just as much, if not more, than a plane ticket. Not only that, the 19 hour second leg of the ride has no food car.

<comment><USER6> This is exactly the thought that occurred to me, except for New York to Atlanta.

I've looked into taking the train a couple of times and balked each time at the idea of paying the same price for 10-15x the transit time. 40 hours in transit is going to be a non-starter for so many kinds of trips, unless you're specifically doing something like [1] where the transit is the whole point of the trip.

[1]: [http://www.viarail.ca/en/explore-our- destinations/trains/roc...](http://www.viarail.ca/en/explore-our- destinations/trains/rockies-and-pacific/toronto-vancouver-canadian)

<comment><USER7> The thing is it is way more expensive to provide a train for 40 hours than a plane for 2. The plane could do 20 journeys in that time, for 20x the nominal revenue.

This is why high speed rail is so good: it can actually really decrease operational costs Vs normal rail as your train, crew, station etc does 2-3x the volume of passengers, and therefore revenue, compared to slower alternatives.

</comment></comment></comment></comment><comment><AUTHOR> Hi All, author of the article here. Happy to answer any questions you may have about the laptop ban, aviation security, TSA assholery, Trump's travel-related civil rights abuses (incl. the "Muslim ban"), or other such topics of interest.

And, thanks for the support... HN is always one of the first communities to upvote my work and help me share it with the world. As a computer scientist turned almost-lawyer, I definitely appreciate!

<comment><USER8> While it is perfectly possible that a scanning device disappeared somewhere, it is not the only way someone can study how to conceal hidden explosive in luggage.

I mean are the people that operate daily these machines vetted to a level where you can totally exclude that they (in ALL airports wordwide) can be affiliated to whatever evil organization and do some tests after hours?

Does the same happen for all technicians that maintain/repair these devices?

Does the same happen for all designers of these devices?

Or if you prefer, do you believe that such a scanning machine cannot be re- built from commercial parts by someone who knows their innards?

Are ALL purchases of new scanners subject to governemnet approval (and even if yes, which government)?

<comment><AUTHOR> Hi jaclaz,

> I mean are the people that operate daily these machines vetted to a level > where you can totally exclude that they (in ALL airports wordwide) can be > affiliated to whatever evil organization and do some tests after hours?

No, although after-hours testing may set off some alarms. I'm sure their on- hours experience would be useful, though.

> Does the same happen for all technicians that maintain/repair these devices?

No.

> Does the same happen for all designers of these devices?

Nope.

> Or if you prefer, do you believe that such a scanning machine cannot be re- > built from commercial parts by someone who knows their innards?

Yes, I do believe that rebuilding a modern, advanced x-ray system from scrap components is beyond the capabilities of ISIS at the moment.

> Are ALL purchases of new scanners subject to governemnet approval (and even > if yes, which government)?

The modern, advanced x-ray systems are not available to the general public. As to how exactly they are controlled, I'm not sure.

See also my comments to other users regarding the differences between modern x-rays and old school ones.

<comment><USER8> >The modern, advanced x-ray systems are not available to the general public. As to how exactly they are controlled, I'm not sure.

Sure they are not something that you can buy at the market around the corner, and surely they would not be cheap, but they can surely be bought by (say) financial institutions, banks, etc. (i.e. not only by airports, and public/international airports).

Now, if you can be sure that no bank (or other private financial institution) nor privately owned airport or port (or similar) worldwide may have some connections with the "bad guys" it's all fine and dandy, otherwise my previous note still stands.

I don't doubt that - as you report - the alarm may have been "triggered" by the stealing (or however vanishing) of the said machine, but from this to consider it "logic" there is a huge step.

At least the last few times I have flown (not to the US that may well have much different and more sophisticated devices) here in Europe I saw everywhere Gilardoni scanners (said to be among the best at least in Europe), like the ones published on their pages:

[http://www.gilardoni.it/en_scanner-a- raggi-x.asp](http://www.gilardoni.it/en_scanner-a-raggi-x.asp)

And are you really sure-sure that all the scanners you can find on alibaba are tat much oudated?

[https://www.alibaba.com/trade/search?SearchText=x-ray+scanne...](https://www.alibaba.com/trade/search?SearchText=x-ray+scanner&selectedTab=products)

It doesn't seem to me like shopping for cruise missiles or the like ...

<comment><AUTHOR> I'm certainly not arguing that DHS uses perfectly sound logic. I'm just explaining their reasoning, however flawed. I agree that this kind of "reactive" security is less than comforting.

</comment></comment></comment></comment></comment><comment><USER9> Read this paper as well [https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper- mowery.pdf) \-- the researchers who wrote it obtained (on the surplus market) the same model of backscatter X-ray body scanner that was deployed in US airports and proceeded to evaluate and validate various schemes for undetectable concealment of firearms, knives, and explosives. Other research was done, including a software implant that would selectively strip indications of contraband from the image (when a specific signal pattern was in the image), and a firmware implant that would disable all interlocks and deliver an elevated radiation dose. If it is possible for a few university researchers to obtain this sort of security scanner without resorting to crimes, it is folly to assume that actual adversaries cannot.

We need better methods for detecting energetic materials (and not just suspicious shapes) in luggage (detecting it concealed inside humans is harder and would require transmission x-ray which is not currently acceptable for airport security screening) that don't crumble when the adversary has unlimited access to the security scanner to test concealment methods.

Concealing knives is kinda easier than concealing energetic materials -- it is, for example, possible to machine a blade that fits perfectly inside a blunt, innocuous "sheath" so precisely (hi, wire EDM) that they appear as a single piece of metal. However, this is not so much of an issue nowadays, as no amount of threatening or stabbing with a knife will make a pilot open the cockpit door.

<comment><USER10> Ceramic, glass and plastic knives can be extremely dangerous and yet they probably don't show up on these machines at all. The utility of these machines is questionable to say the least.

Bruce Schneier observed, like you did, that the heavily secured cockpit door is one of the only real improvements made to airplane security in the last few decades.

<comment><USER11> > and yet they probably don't show up on these machines at all

Uh, yeah, they do. Have read _anything_ about backscatter xray machines?

The real way to defeat these machines is to hide things in folds of your flesh. It can see through clothes, but not too much skin. In staged demonstrations, fat people have gotten a metal pistol through, no problem.

<comment><USER10> I've read a fair bit about these machines and seen various demonstrations back when they were still being deployed.

Quick examples: [https://www.wired.com/2014/08/study-shows-how-easily- weapons...](https://www.wired.com/2014/08/study-shows-how-easily-weapons-can- be-smuggled-past-tsas-x-ray-body-scanners/)

A gun(!) is basically invisible in the scan. Is teflon tape enough to defeat these stupid machines?

</comment></comment></comment></comment><comment><USER12> The premise is flawed. X-ray inspection equipment is easy to find - it's regularly offered for sale on EBay and you'll find a number of teardown videos of various models on Youtube. The stolen X-Ray equipment is not being reported probably because it isn't particularly interesting.

<comment><AUTHOR> Well, not exactly. Very basic x-ray equipment is easy to find on eBay. The more modern equipment that the TSA uses is not available on eBay...

[https://securitytoday.com/articles/2008/07/30/tsa-to- expand....](https://securitytoday.com/articles/2008/07/30/tsa-to-expand.aspx)

"Advantages of AT X-ray include a greatly enhanced image with the ability to target novel threat items resulting in fewer bag checks and faster throughput, and the ability to upgrade the system with enhanced algorithms."

...and that article describes the 2008 edition of the technology!

For a more technically-specific perspective, I can say that the newer machines take images from multiple angles and are closer to a medical CT scan than a old-school x-ray. Owning one would allow you to practice placing your items in a direction and location that would be least able to be seen by the operator.

</comment></comment><comment><USER13> This article seems to miss the fact ISIS took over Mosul international airport in 2014. Surely they got luggage screening machines in hand by then already.

<comment><USER14> My guess would be that the gear at Mosul would not be as advanced as elsewhere.

<comment><USER15> Not sure, because the destinations countries for the planes departing from there have some interest (a bit like the US forcing some theater on Europe), and there is some international help for military and security theater gear.

</comment></comment></comment><comment><USER16> Hey look, a security crisis that can only be fixed by requiring that we prove our devices are functional, most likely by turning them on, logging in, and showing that there are a few documents present. And in some cases, extra manual evaluation will be required, entailing taking that logged-in laptop into a back room for further inspection. They won't copy everything onto a disk of their own---honest!

<comment><USER17> Even forcing people to turn on devices doesn't really fix it. Just keep three (for proper voltage so you don't have to add any boost circuitry) of the cells in your battery bomb and it'll be more than enough to pass their screening.

<comment><USER16> Whether this actually helps security is irrelevant.

</comment></comment></comment><comment><USER18> Everyone seem to have missed the opportunity here to push for standard power connector/polarity/voltage/maxcurrent requirement for all laptops while fitting a power cable (with short circuit protection in every seat. That will also discourage from producing laptops not working if a battery isn't plugged in. Having say a 12VDC/3A plug in every seat will force most manufacturers to make at least one airline-friendly laptop, and/or implement on faster models things such as turning off cores and keeping CPU speed low to stay within that current limit.

edit- and push to get a standard for battery pack sizes to reduce the number of form factors, then implement a service where you give your used one at departure and get a new one at arrival.

Regulations like that one stink badly, but necessities drive progress and I see an opportunity here.

<comment><USER19> > edit- and push to get a standard for battery pack sizes to reduce the number > of form factors, then implement a service where you give your used one at > departure and get a new one at arrival.

Or we could implement the Indian system, where you turn in your new batteries at departure and are given used ones on arrival. (Mysteriously, despite the assurance that they are the same batteries, they have sometimes changed brand, too.)

</comment></comment><comment><AUTHOR> Hi Everyone, author of post here with an update for you. The most modern x-ray systems in use by the TSA at airports to screen carry-on bags can indeed see through lithium batteries. It also differentiates densities, and it seems to me that the latest tech should therefore be able to indicate the difference between a battery and C4 in a battery-shaped box. So is it that the airports subject to the laptop ban have the older tech? Well...

Read more: [https://professional-troublemaker.com/2017/05/22/update- newe...](https://professional-troublemaker.com/2017/05/22/update-newest-tsa- carry-on-x-rays-can-indeed-see-through-laptop-batteries/)

</comment><comment><USER20> Q for the author: how valuable would an actual proprietary airport X-ray be, in terms of designing devices (as compared to another X-ray of similar spec)? Does having access to the actual X-ray for purposes of product testing really make that much of a difference to a technically gifted bomb-maker?

<comment><AUTHOR> Yes. See my comment below to djmdjm, but also, I'll add one more thing. Take a knife out of your kitchen drawer and hold it in your hand in front of you such that the sharp side of the blade is on the left and the dull side is on the right. Easy to see. Now rotate it 90 degrees such that the sharp side is facing you and the dull side is facing away. Much harder to see, especially if you can imagine what it would look like on an x-ray, and how you could further conceal it by carefully placing other items between the "camera" and the item.

<comment><USER21> Angle-shifting units make this harder, but the obvious blindspot is the conveyor belt entrance/exit holes (they cannot have imaging equipment in them).

<comment><AUTHOR> Exactly. Imaging devices all have blind spots, which is how I was able to defeat the TSA's body scanners in 2012.

</comment></comment></comment></comment><comment><USER22> As lithium batteries are opaque to X-Rays, perhaps a ban on laptops with batteries should be considered. This will surely push for standard swappable batteries and standard power supplies so the laptops could be used on board without batteries.

<comment><AUTHOR> What? No, that's a wholly unnecessary solution (though more standardization of batteries would certainly be nice). Swab the outside of the laptop for bomb residue, which would be especially difficult to clean from a laptop because the stronger solvents to clean with (like acetone) would mark the plastic. Or hire more dogs. Or make a "puffer machine" for laptops (blasts with air and then samples the air for explosive trace). Or come up with another solution -- this is HN! :)

<comment><USER23> Is the puffer machine a thing? Or you just came up with it?

<comment><USER24> Nope, they're a thing:

[https://en.wikipedia.org/wiki/Puffer_machine](https://en.wikipedia.org/wiki/Puffer_machine)

> _The machine operates by releasing multiple puffs of air at a passenger who > is standing upright within the machine. This will flush out any particles on > the person inside the machine then analyze and identify them in seconds.[6] > According to an article in the 16 June, 2005, New York Times, it is capable > of screening up to 180 passengers an hour.[7] This sample is then analyzed > using IMS or MS technology to search for specific explosive or narcotic > compounds. If a substance of concern is detected, the security personnel are > notified by a visible and /or audible alarm._

</comment></comment></comment></comment><comment><USER25> It seems to me that if an X-Ray scanner was stolen from an airport, that information would reasonably be considered SSI due to its relation to screening passenger luggage. I wouldn't be comfortable spreading news that stolen equipment is available, that there's a security vulnerability allowing equipment to be stolen, that ISIS is in possession of the stolen equipment, or any vulnerability assessments of the equipment. The unnamed source seemed convinced that any security decision was made to avoid scaring "mom from the midwest," but that comment appears short-sighted if anything more than conjecture.

</comment><comment><USER26> >By forcing all these batteries into the cargo hold where a fire cannot be rapidly detected and contained, DHS would be countering any deceased risk of terror with an increased risk of fire.

Everyones always been telling me that if I want to bring down a plane I should set the cabin on fire, not the cargo hold. Have I been living a lie?

</comment><comment><USER27> Correct me if I'm wrong, but wouldn't a relatively benign way to fix this simply be that the TSA agents randomly reorient/flop some carry on luggage items in the bins before they go through the scanner?

<comment><AUTHOR> That would definitely help. Or, simply re-run bags where there is opaque stuff that the screener is unsure about, oriented in a new direction. But, that wouldn't necessarily solve all the problems, as laptop batteries are opaque in all directions, and so if you got a lead metal box and filled it with explosives, it may look much the same.

</comment></comment><comment><USER28> So instead of creating new measures in order to fix the security problem, they chose to flood the system with false positives...

</comment><comment><USER29> Reduced airline travel, tourism, and global trade -- sounds like a good action plan for countering global warming.

</comment><comment><USER30> ya right, fuck off TSA. They're just trying to pretend they're relevant.</comment>


The Grounding of the Royal Majesty (2009) [pdf] - <AUTHOR> http://ti.arc.nasa.gov/m/profile/adegani/Grounding%20of%20the%20Royal%20Majesty.pdf

<comment><USER2> TL;DR: On a large cruise ship the GPS antenna broke, and the GPS continued to display plausible coordinates based on dead reckoning with only a tiny icon to indicate the data wasn't based on a satellite fix. The dead reckoning error accumulated to 15 miles, which drove them aground near Nantucket.

<comment><USER3> Actually I think the real TL;DR is that the crew failed to "trust but verify" and that the automated cross checks were set up in such a way that they cancelled each other out. It's a cautionary tale for anyone developing self- navigating devices.

Plus for me the document is cut off mid-sentence.

<comment><AUTHOR> _Plus for me the document is cut off mid-sentence._

It's a copy of a book chapter, plus the end notes (notice how the page number jumps near the end). The end notes aren't paginated by chapter, so you're seeing the first paragraph of the end notes for the NEXT chapter at the bottom of the page.

</comment></comment></comment><comment><USER4> This is _really_ well written, the author has a very engaging story-telling style, and manages to get the facts across while still being entertaining. And, I love the Proverbs quote at the start. Anyone know what book it comes from, as I'd love to read it if all the content is like this.

It appears to be the entirety of Chapter 8 of something, but I couldn't find the actual book title mentioned anywhere...

<comment><USER4> Degani, A. (2004). Taming HAL: Designing interfaces beyond 2001. New York: St. Martin's Press/Palgrave Macmillan. 320 pages, 105 figures. ISBN: 031229574X

The book details a new approach, mostly based on software engineering and formal methods, for the describing, analyzing, and identifying potential design errors in human-automation interfaces.</comment></comment>


OneExtraLap Launches To Public, Wants To Reinvent Social Quizing - <AUTHOR> http://spncr.me/oel

<comment><AUTHOR> So proud of my friend stephen Ou for launching this. It's really impressive and quite addicting. :)</comment>


Entrepreneur Log  - Day 22 - <AUTHOR> http://www.eytanlevit.com/post/35263054728/entrepreneur-log-day-22

<comment><USER2> Same here - blogging everyday my startup progress. It's motivating. Good luck to YC applications. I've applied for the same batch. =)

<comment><AUTHOR> Great blog, I've buffered it.

If you need any advice from a technical guy - feel free to reach out, I'm glad to help.</comment></comment>


This website requires JavaScript - <AUTHOR> https://angular.io <comment><USER2> Also, it took a couple of seconds of staring at the world map near the end, as it has almost invisible continents. Initially it was a matter of connecting the dots.

So did they follow Google's new "Sterile Design" standard?

</comment><comment><USER3> You would expect best practices from the Angular team. Why doesn't this work without JavaScript?!</comment>