I bought 2 smart TVs recently and was able to turn all this BS off by simply not accepting the privacy policies during setup. Of course this means you can't use the built-in netflix apps or check for software updates or whatever but that's fine by me. I left both on my network for a period of time as well to check (via DPI) and indeed neither one was actually doing anything on the network other than pinging a software-update server every few days.
Thanks for sharing this! I had to go disable this "feature" on the "Smart TV" my family has. Turned off "Viewing Information Services" and "Interest Based Advertising". It was on by default!?
Having worked with Erlang for few years. I still don't understand the new hype behind it.
Ok, the Beam VM have a lot of good ideas. But I think that API of OTP and the language itself do not help to make concise and maintainable code.
And you're pretty much on your own about tooling. I really think that even if you can achieve good performance/scalability in theory, in practice your team become less productive.
Was that a long time ago? The tooling has improved massively after Elixir and Hex appeared. The upcoming “Adopting Erlang” book goes into that history a bit:
I think it's about Elixir. Personally I won't start a web project with Erlang: it's too hard to read and to write, it makes me feel like I'm still in the 80s (it's when I started coding.) Elixir is almost 1:1 with Erlang and I'm much more comfortable with it.
I can't say much about tooling because I never really worked with Erlang, only some toy programs. Elixir's tooling seems to be on par with what I'm using for Ruby, JavaScript and Python.
It's better than those. I can write an integraion test that leaves the vm via http request a comes back in and the http handler only views a shard of the shared state of the system associated with that particular test. That's a concurrent integration test. You can't really do that reliably without the BEAM.
Thanks to Elixirs macros, the code for this subsystem is about 75 lines of code and in order to use it in a group of tests it's a single "use" statement at the head of the test, and the hooks inside of the main part of the code are compiled to no-ops in prod.
Other OTP based languages have different standards for API consistency, developer comfort, and documentation, and generally feel 'more modern' in those respects. That's probably where the hype is coming from.
Really? This is a native macOS app. It would have to be entirely recreated for other platforms, which is a waste of time and resources for an MVP. If this were a multiplatform Electron app, it would be getting criticism for being an Electron app.
To be fair, it never really was. Mac and Linux were always after thoughts to Windows. Now things are trending towards Mac first, leaving Linux and Windows looking outside in.
I actually did with my company and anyway it was a bad decision.
JavaFX and swing customization is really not easy and not well documented. JavaFX uses custom XML which make no sense to be honest when you want to do nice design.
And it requires custom CSS too.
Additionally, their design are bad(I mean their Java API).
We spend a whole year making an app with it, at the end we decided move away from it, like the rest of the java community if fact that do not really support desktop applications anymore.
> JavaFX uses custom XML which make no sense to be honest when you want to do nice design.
I don't see why the custom XML should be a problem. Definitely you are not supposed to edit the .fxml files by hand, especially when you have apps like Scene Builder that allow you to design everything from a GUI.
> And it requires custom CSS too.
That's true only for a few JavaFX-specific properties. The CSS syntax doesn't change very much. Also, it's not a surprising feature: QT, the C++ GUI framework, also uses custom CSS.
Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be.
React can appears complicated when beginning, but it pays off on complex apps.
People keep on saying this, but I've written complex apps with both Vue and React (using state stores) and there don't to be any apparent scaling differences. They even use the same component model (virtual DOM, props down, events up).
There are some claims that Vue uses two-way-binding which is unmaintainable, but v-model isn't true two way binding and is just syntax sugar for builtin tags: https://v1.vuejs.org/guide/forms.html
With React, you would have to explicitly write the event handler/setter out, and some may prefer explicitness (but again, there's nothing stopping you from doing the same with Vue).
Vue just has some nice features (computed properties, better style scoping, etc) and different methods for inheritance/templating (but you can use ES6 classes and JSX if you want to), and like somebody else mentioned, is plug and play (yes, you can technically write React render functions without a transpiler, but do you want to?) while Vue (with the template compiler bundled) lets you write templates with HTML attributes using just a script embed.
There are a bunch of other arguments that are more nuanced (ecosystem, bus factor, etc..) but from what I've experienced, Vue is no worse at scaling than React simply because they share the same conceptual model.
Sounds like I'll have to try it out! Definitely don't want to put all my eggs in the React basket with all the patent stuff right now so would like some experience of the alternatives.
If you use single file components, there are some common compile time checks by default for the render function, but I'd argue that type checks are not as necessary as in JSX (which you can use with full type checking in Vue) due to separation being encouraged.
If you are using uncompiled components (newbies using script embeds) with no build step at all, there are clearly no compile time checks. IMO this is why Vue is significantly more newbie friendly.
This is totally not true. It depends on how you structure your project. Vue is good for simple things but it scales way better for large complex apps than React.
Why? Less boilerplate. And less boilerplate = less code to maintain. Vue HTML template functions are really well designed with just enough functionality to make your life easier but also encouraging you to build custom components when you need something custom :)
My only suggestion for people starting with Vue is to not be afraid of directives (Vue directives are nice and have nothing to do with Angular directives), group your .vue components into directories and don't jump into Vuex right away (same goes for React beginners, don't force yourself to learn Redux for your 1 page app).
you should try mobx + react for 'local' state management. mobx provides something similar to vue (MVVM), and the amount boilerplate becomes somewhat like vue's
Sorry but that's not true. We have a pretty heavy VueJS application in production with like 500 components and it's a pleasure to work with, and is still quite performant.
This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.
I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.
For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): http://f37foundry.com (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.
> please visit this site using some recent version of [browser that sends all your data to Google]
slowclap
If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).
It's just the type tester element which is not accessible with browsers other than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to make it work which didn't work in Firefox.
As mentioned in my other comment, due to the target audience it was decided that it wasn't worth the investment to get it working on other browsers right now, but the rest of the site should still work.
Not React's fault, just a lack of time/budget and a lack of native browser support for advanced typography.
Managing the state and rendering of all the text items as the user manipulates them (this is on the desktop "type tester" homepage, not mobile) - essentially trying to build a "desktop-class" (to some degree!) experience à la Adobe Illustrator.
The rest of the site is pretty basic granted. Maybe it's not a great example, but it's the sort of thing that could have easily become unmaintainable in the old days as features were added quickly, but React and the component model (and MobX) made it much more manageable even as I hacked things in last minute ;)
Cheers, I intend to try it out. Curious to see how their React Native equivalent works, huge selling point for React IMO but I should try the alternatives!
I mean for the simple use cases like adding some validation to a form or a simple widget on a site. But in my experience, these projects usually grow to the point where you are glad you went with React. Personally I'm a huge fan and build things with it I couldn't have imagined doing a few years ago, so I hope all this patent stuff gets resolved/blows over.
I’m curious, how did you manage to build a website that claims to work in Chrome, but not in Chromium? In Safari, but not in Firefox?
And worst of all, it actually obviously works in Chromium and Firefox, but you just check the UA.
Works:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Doesn’t work:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.90 Chrome/60.0.3112.90 Safari/537.36
I mean, sure, if you want to build a site that relies on ridiculous UA testing, and breaks everywhere, sure.
But not even in the "works best in Netscape" era did people actually intentionally break their pages in browsers where it actually worked. This is a new low. This is completely ridiculous.
Proof: http://i.imgur.com/YlPE77b.jpg Oh, and as you can see, if I spoof the UA in FF; it actually works fine. This is completely bullshit, and I’m sure I’ll never do business with you. This is completely ridiculous, leaving out major browsers (and, for example, over 40% of the desktop browsing market in Germany) intentionally and unnecessarily.
Ultimately this was a client project with a fixed budget and timeline so a decision had to be made between extending browser support and adding more features.
Given the target audience (graphic designers, the vast majority of whom are on Mac and will use Safari or Chrome, as I validated from stats on other sites I've built), the decision was made to focus work on the type tester on those browsers.
The rest of the site should still be accessible with any browser, but we decided it was better to not show the type tester at all than have a broken experience (which was the situation with Firefox).
Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
> Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
It doesn’t even work on Chromium, in the same version as Chrome. There is literally no excuse for that, it’s literally the same browser engine.
On top of that, even back in the "best viewed on netscape navigator 4.0" era there was a solution for this: Show a message that it was only tested with browser X, and that your client was too cheap to pay for anything else, but at least allow the user to bypass that.
As said, the excuses convinced me even more to never do business with you.
This is behaviour that's harmful to the web as a whole.
The loop of "everyone only uses chrome" → "I only need to support chrome with my website" → "nothing works on firefox, I'll switch ti Chrome" is harmful to the entire internet industry, and the startuo economy.
It is harmful to all of us, and hurts all of our future.
I am getting more aggressive because the other person completely ignores the effects on the surrounding ecosystem, and does not even consider a solution that would provide a compromise, as the "optimized for chrome and safari, ignore and use anyway" button would provide.
I see their situation, and their limits, but this is a very egocentric opinion that completely ignores the effects on the rest of society, which is an issue that's just all too common (see also monopolistic effects, or environmental effects, etc).
Good point about Chromium, I'll change that - it wasn't deliberately excluded. But disagree about the messaging, in this case it was more important to the client that the feature worked as smoothly as possible than that everyone could see it. In some cases I'd disagree, but given the narrow target demographic (and their browser choices) here, I think it was a reasonable choice.
I've been a happy customer for years. The contact is [email protected] - it's on the pricing page. I've emailed support a few times and they answer very promptly.
Rsync.net has been around forever - like 15 years. They predate the concept of 'cloud'. They were the first to use a 'warrant canary', in 2006. (https://en.wikipedia.org/wiki/Warrant_canary)
RE the warrant canary: all legal analysis I've seen points to the canary being functionally useless. A court would throw out the defense immediately, removing a canary pointing out that a warrant has been served is the same as tweeting that you got a warrant.
It's the minimal legal hack: completely useless in a court but massive generator of internet comments
Though it generating discussion around the warrants themselves is a good feature
It's still useful as a rhetorical tool against enforcement. If someone gets imprisoned for saying "no comment" and refusing to actively lie, that would hopefully cause an enormous outrage.
The idea is that forced speech is different than free speech. That means that someone can force you to not say something, but not force you to say something.
- The government cannot force you to update the canary. A court cannot get you to update it, because it's forced speech to demand an update.
- You created the canary of your own accord, and are responsible for its effects. Not updating the canary is, effectively, speech.
Though, from [0]:
"Realistically, though, courts compel speech all the time. Court-ordered apologies, disclosures, and notices are not unusual. And if ever a court would be inclined to compel speech, it would be in a situation like this one, where a company intentionally set out to get around a gag order with this kind of convoluted sea-lawyering."
Decoupling your physical mailing address from your office location makes a lot of sense, since changing the address would be very disruptive. Same reason you'd use Google Voice over giving someone your direct number.
And more and more companies these days don't even have any fixed physical offices, with remote-first cultures. What's the address of Trello? You won't find it on trello.com
It's not like you're going to actually walk there. If it's a legal address registered for the company, that's enough for every interaction you need with them.
It's unfortunate that you're being downvoted just for being cautious/skeptical.
Various aspects of rsync.net are periodically discussed on HN. About 417 days ago I raised a similar issue to yours, namely who is behind this company and what is the address.
At that time the owner responded on HN with clear information. It's unfortunate that, more than a year later, their website is still a bit of a dog's breakfast on this issue.
What makes my suspicious is that I can't find any information on the company itself anywhere on the site. Where are they headquartered? What's their contact information? It's not even clear under what jurisdiction they operate.
Again, we had all of this in place prior to an ill-advised website redesign.
As I said higher up in this thread, I'll make sure this gets republished and put in place properly today and I will add some verbiage that addresses your specific point about HQ and jurisdiction.
In the meantime, I will confirm we are a US firm with locations (ie., our own racks - not rented hardware) in San Diego, Fremont (San Francisco, basically), Denver, Zurich and Hong Kong.
Phys-sec means you don't just advertise your location, and keeping control over how people can contact you is another way to prevent social engineering attacks.
