I don't understand the point of bypassing, the creators need to make money, if you can afford it, subscribe, if not, use another website. it's that simple
I subscribe to a couple of sites. I won't be subscribing for an extra monthly fee I can't afford just to read one or two articles linked on HN. Therefore I have two options: don't read the article, or bypass the paywall.
In both options, the outcome for the site is exactly the same. So, not being a masochist, why shouldn't I choose the outcome that benefits me without harming anyone else?
But it is harming someone else in a way, they only want you to read it if you pay for it, there will still be bandwidth costs to cover for people who bypass the paywall, some might argue that in some paywalls, the content is already sent to your browser anyway but that's a whole different story.
It's the same argument for piracy, "if I make a copy, I'm not taking away the original, so I'm not stealing", which is just a lie to tell ourselves to feel a bit better at the end of the day.
I agree it's the same as in piracy, and I do the exact same there - pay for what I can, download the rest.
Regarding the bandwidth costs, those are absolutely negligible, since the methods for bypassing the paywalls either only fetch the text (e.g. http://outline.com) or cache it on other servers (e.g. http://archive.is).
It is definitively not what they wish, but not complying with someone's wishes is not harming them.
--
On that last point, while I don't take my moral code from the law, I note that it agrees with me; for example, even if you have a contract with a guy to build your house, and you say your want a certain brand of pipes, but he ends up using another, you're not entitled to anything. Unfulfilled wishes are not harms.
I personally don't think it's something "wrong" with you, most probably there's something wrong with your process.
I have the same issues, and I think you speak out for lots of people, motivation is a very limited resource and when it's not used properly, you end up in this state.
What worked for me best is to tackle your tasks with the notion that you have limited resources in mind and that you're just human.
Some tips that you might find useful, that certainly work very well for me:
1- Declutter your workspace, clean your whole house, having small things here and there lying around affects my thought process.
2- Declutter your brain, Throw away ideas that might be nice, but are not possible to work on right now cause they'll take tons of time and money, write those ideas down somewhere for later use, if ever.
3- Declutter your life, make sure you don't have lingering problems that can be fixed now, your brain will fatigue out when you have a lot in your stack, fix that leaking toilet, talk to your spouse about the issue you've been always having with them, tell your friend you can't help them with that thing they needed, empty out as much as you can, and work on the low hanging fruits first.
4- When it comes to tasks, spend as much time as you can afford planning it ahead first, break things down into small actionable tasks that will take a few minutes or hours to resolve, avoid homogeneous tasks like "Implement backend", "Fix the known bugs", "Release next version", etc... instead, have very concrete minimal tasks like "Fix bug #21", "Create Users profile database schema", "Convert header image to SVG", etc...
5- Timebox things when planning, say you'll spend only 1 hour today working on this issue, if you can't, then take it again in the next planning and break it down further and give it an appropriate time slot
6- Getting great ideas while working is almost like thought cancer, don't start on them, write them down and continue to do what you are doing
7- Don't start new tasks before the assigned ones are actually done
8- Don't reward or punish yourself, rewards tend to make me very narrow minded, and punishment takes the fun out of things, ask yourself why you are doing what you're doing and why you have to do it, write that down and keep it as a reminder in your workspace.
9- Talk to others, let people know what you're doing, and when it's expected to be done, this keeps me at least from getting lazy as there's expectations form others to see what i've done
10- Listen to different music, I noticed that once I changed my playlist that was on repeat, I was a completely new person, play a podcast instead, or listen to radio or channels that you have no control over.
11- Kill the projects that are taking too long and deep inside you you know that you'll never manage to finish, find smaller ones that are realistic.
12- Always remember that nothing has to be perfect, it's better to have something out there, most of the time no one even notices what you think is a crisis.
13- Ask yourself everyday, is this what I want to be doing?, am I happy?, should I continue? if the answer is truly a big yes from your heart, then go on, if not, try to find other things that might be more fun for you.
Tis is what works for me, your results may vary, but what matters is that you have to be relatively happy doing what you do!, if you think you're suffering from ADHD, I would say it's best to visit a therapist, it'll clear out lots of things, don't feel bad spending money on yourself a bit, it's worth it. also if it's your kind of thing, find a mentor :) keep up the good work and never give up!
About timeboxing - Edmond Lau explains like this on The effective engineer: "instead of researching for a solution (say CSS library) for a few hours (which become days), give yourself (say) one hour for that and use the solution you were able to come up. Its interesting and certainly hits me hard, because researching is so much easier than working...
Take it easy on yourself mate ;), you are not Euler, and you don't really know what kind of father he was, you never know maybe you are doing a better job and got different priorities!, good luck and keep pushing!
1- You don't have a way to show customers how this actually works, I have no idea what i'm signing up for, so I won't sign up.
2- You don't actually use the button on your own company's website, but use only a contact form, which tells the users in a way that you don't really use your own product.
3- You mention mobile app, but there's no where for it to be found.
> It would greatly improve the networking of these games.
This is not accurate, i know it's like a rule of thumb that UDP is faster than TCP, but that's naive, there are cases where UDP will end up being slower, and to be honest, it depends on lots of variables, and at many times, the congestion control, packet ordering and all the bells and whistles that comes with TCP is well worth the little performance penalty, assuming that in that specific case it actually is slower than UDP
And of course if I'm wrong, someone will let me know :D
UDP provides massively better quality of service for realtime data wherein there aren't usually dependencies between particular pieces of data.
For example, if you are transmitting the position of some guy in a world, N times per second ... and you drop one particular packet ... that's fine, you just get the next one and you have more up-to-date information anyway.
TCP will block the entire connection when that packet is dropped, waiting until it is received again, and not giving any of the subsequent information to the application. This is bad in THREE different ways: (1) By the time the new position is received, it is old and we don't care about it any more anyway; (2) Subsequent position data was delayed waiting on that retransmit and now most of that data is junk too, EVEN THOUGH WE ACTUALLY RECEIVED IT IN TIME AND COULD HAVE ACTED ON IT, but nobody told the application; (3) Other data on the stream that had nothing to with the position was similarly delayed and is now mostly junk too (for example, positions of other guys in totally other places in the world).
It is hard to overstate how bad TCP is for this kind of application.
You are absolutely correct, but not all games are FPSes, I just think that the generalisation in the premise that UDP is better than TCP for networked games is naive, you have to put into consideration the type of game and what data is actually being sent.
What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
The main exception is low-number-of-player token-ring style games like RTSs with tons of units. Those usually simulate in lockstep, with the full state of the world extrapolated from inputs that consist of a very small amount of data. This means network traffic is relatively low, but in order for this to work you have to have complete knowledge of everything and exactly when it happened, which means no packet loss can be accepted and everything must be processed in order. So then you have the same kinds of problems as with TCP (even if the underlying transmission is via some other protocol) ... thus these games operate with some large amount of latency to hide these problems.
But, this network design is only the case for a minority of games. Just about any modern multiplayer game that is drop-in/drop-out, where the developers really care about quality of experience, is better off going UDP. (This is not to say that developers always do the best thing, since it's much easier to just say screw it and talk over TCP and call it a day. The temptation to do this is heightened because of all kinds of problems with NAT punchthrough and whatnot; because so much traffic is Web-oriented these days lots of routers mainly care about that, which causes all kinds of interesting annoyances. Thus games that do talk over UDP generally fall back to TCP if they are unable to initiate a UDP connection).
Well, there is one other case of games that run in lockstep, which is when they are console games made by developers who want to avoid incurring the costs of running servers (which are often much higher on consoles because the platform holder charges you out the nose). When you are running in lockstep like that it is more like the RTS scenario above, and thus it doesn't matter much if you use TCP because you are already taking the quality hit. But this is a cost-cutting kind of decision, not an it's-best-for-gameplay kind of decision.
P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
> What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
You misundrestood what I'm talking about, I'm not talking about the camera position, I'm talking about different games like turn based games, chess, board games, etc..
Lockstep is out of the scope here, surely not needed in a chess game. I'm talking deterministic games here.
> What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
Again, out of scope, I'm saying UDP is not the answer to all games and the assumption that if a game is networked then you should go with UDP is naive as I'm trying to say, forget open world, forget FPS, think about a simple turn based game.
> P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
Where did I call anyone naive ? thre's a difference saying you're naive and saying "the assumption is naive" I do believe i know enough that's why I'm commenting in the first place, even though I stated I might be wrong about some points, I did not personally call anyone names, go back and read my comments.
What people usually want is all the bells and whistles of TCP without the occasional huge latency spike introduced by the guaranteed ordered packet delivery to the application layer.
Unfortunately, all the alternatives (SCTP etc etc) seem to have foundered, probably due to aggressive filtering by border routers/firewalls making it impossible for alternative protocols to gain traction.
Exactly my point about the whole "many variables involved", many networks still filter UDP as you say, which is really bad if you want to make sure everyone can use your game
SCTP droped 100% time as there no proper PNAT available for it. To make traction other protocols there need "happy eyeballs for transport" so it can be transparent for end-users
You are wrong, I would attack your argument if you gave one beyond that TCP has some convenient features but you didn't. So all I have to say is that you should try playing slitherio agario on an internet connection that isn't in a metropolitan area.
I'm surely wrong at many things yes, but you are also wrong at some points, if i play a game in a bad network setting, UDP will still be a bad option, packets will be probably very mangled on a bad network and will offer no superiority over TCP, you will see more blockage on TCP, but you will probably also see your player jump all over the place with UDP coming in totally out of order, and if you implement your own way of reordering packets, then you are almost reimplementing TCP over UDP again. if a network is bad, it's bad no matter what networking protocol you'll be using.
The only thing that makes UDP faster is that it comes without TCP's convenience features, and for many games, this is more than enough and the performance penalty is not usually worth it (unless you're a AAA with lots of resources and dedicated team just for the networking part)
besides that if you simply opt-in to UDP because it's better, then you'll spend much more time working on the network than actually working on the game.
my problem was with the generalisation in the premise, that `UDP is better than TCP for networked games`, this is not the case for a deterministic game of chess or any card/board game.
UDP's only point in this article is realtime data intensive games like FPS'es.
also I'm not putting security into consideration in this argument.
then you are almost reimplementing TCP over UDP again
you implement TCP features only when you need them. player positions for example are not critical, you can miss some but your game would still work if you are interpolating things correctly. if your player position message gets lost, you don't need it anyway you only need the newest position. same goes for order of the packets, if you are not needing such a thing, your lost packets would delay everything in the game.
For these reasons, TCP suffers a lot more if the network is bad. You really don't need to be a AAA company to implement TCP features on UDP.
UDP's only point in this article is realtime data intensive games like FPS'es.
Well article says, as you quoted:
> It would greatly improve the networking of these games.
And 'these games' are he means real time games like agario. It is not a FPS but it is a real time game. There is no reason to use UDP if it is a turn based game, like a card game. But a real time is pretty much always would be better with UDP
Totally agree with you there, but player position criticality is not for me or you to decide, it's game dependant, my worries is not about dropped packets, but packets that are in the wrong order, only in a game where combat has to be precise I would say it's critical.
Yeah you don't need to be a AAA for sure, i was exaggerating a bit to make my point, what i'm trying to say is that newcomers to gamedev will end up struggling, TCP isn't easy, neither is UDP, without proper understanding of both protocols there will surely be mistakes made.
I do agree with the article 100%, I'm not saying in that use case that TCP is better, I'm just disagreeing with the premise as it's a bit vague and implies that you know what agar.io and slither.io are, I know both games and i know they're realtime, but there are people out there who don't know what they are, so I'm saying that just thinking that UDP is faster than TCP so it's best for networked games is naive, a better way to say it is just mentioning that this is for realtime games, better yet realtime games that can't allow network delays and are not critical, WOW for example uses TCP for some parts of the game that are not critical, where player position doesn't really affect the game, they end up with huge latency now and then, but the game is programmed in a way that some latency won't matter. in other cases they use UDP, that's also one of my reasons to say that UDP is not the only answer.
So yes, you are 100% right, and the article is 100% right, I just don't like the premise (the way it was written at least)
Everyone seems to miss the whole point of my comment up here, so here is what I was trying to say:
1- UDP is not always the answer, don't overcomplicate things, I'm trying to say that there are games like chess,board games, basically deterministic games that are not realtime. it is very wrong to use UDP for that game style, it's just a huge overkill.
2- UDP can in fact be slower for some use cases than TCP, there are lots of variables and unknowns.
3- Just opting into UDP because "it's faster" is very wrong, before jumping to UDP, there is a whole lot of networking theory that needs to be learned, and I'm not concerned about AAA here, I'm concerned about new beginners and indies that will read this post and think that this is the only right way to do things.
4- UDP is filtered on some networks still, you'll lose some players
5- If your network is so bad that TCP is not fast enough or that older packets are blocking newer ones, it'll be the same with UDP, packets will come in mangled and out of order, ant the game's "Quality" will still be bad with your avatar flying all over the place. until the developer implements a way to reorder packets, which is still more work.
6- I'm not a network professional, neither are lots of people. and if you don't have a strong knowledge to make sure your game's networking is in top shape you might end up making mistakes that will cost to fix.
7- The premise that UDP is going to greatly improve the game networking is naive (It's ok to call things naive by the way, don't be too sensitive) I'm a big fan of gafferongames, there are tons of great resources there, I'm only saying the premise is naive, not the person who wrote it. of course the author knows what they're talking about and I do understand they mainly target RTC and games like agar.io, I would want them to state more clearly that this is only valid for non deterministic, RTC, FPS, whatever you call it. for other cases, it's not the best.
8- Security wise, I'm not sure how easy it is to secrue a UDP conection, but it's surely not straightforward and easy as TCP with SSL for example.
Finally, there is never one true answer to your project's networking technology, lots of developers mix and match between TCP, UDP to get best of both worlds
I would just say use whatever works best for you as long as you have enough knowledge and good reasoning to back your decision on what to use!
I don't think it's illegal or wrong to have that search, those mistakes are made by developers who aren't paying attention to security, and from experience those leaks will never be resolved UNTIL they get widely exposed, until then, lots of those people will just shrug it off.. you're actually doing a favour to the users who depend on those developers, you never know when the next leak will be and it might be stopped by forcing the developers to fix it. it's not about you, your service, nor the companies, developers who are leaking secrets like that, it's about the end users and people who are affected, my two cents, put the search back, expose it, it's already exposed and probably black hats already have the secrets and don't want to notify the devs of their mistakes. anyone else who disagrees with you doesn't really understand how big this is, your service is amazing and I totally appreciate the work you did, if someone thinks you're "getting attention" or "evil" they really are not looking at the big picture, the "evil" ones are the people who already have that leaked data and keep it for their personal use.
+1 on removing it completely, you need a privacy policy link instead, you might create one your own with some online template or better yet have a lawyer write it for you, shouldn't cost so much I guess and will give you the professional look you're trying to show
>I don’t know about you, but the idea of having a fully capable web browser in my pocket was a huge part of the appeal.
A: Both iOS and android have fully capable web browsers, I'm not sure what's missing here ?
>I’m talking about stuff that QA should have caught, stuff that if anybody at Apple was actually building ? apps this way would have noticed before they released.
A: They do pass QA, that's why features are removed
>One quick example that bit me was how they broke the ability to link out to an external website from within an app running in “standalone” mode. target=_blank no longer worked.
A: Thank god apple no longer allows that, how do you expect a tiny screen to have popups and switch web browser views when you click links ? this is a very bad UX.
>We were running a chat product at the time, so anytime someone pasted a URL into chat it was essentially a trap.
A: I'm not here to judge your decisions or why you did it that way, but IMHO a chat product doesn't really belong in a "web browser"
>The message from Apple seemed clear: web apps are second-class citizens on iOS
A: Exactly, and it is that way for many good reasons.
I see you've mostly switched to android just so you can continue developing webapps, that's okay for you, but it's not a really good reason at all.
Don't be like the people who where bashing apple when it decided to remove support for flash player, because that's one of the reasons the web has
become the way it is today, i'm not an apple fanboy, i also did the switch from iOS to Android after around 7 years too.
According to that, it does not work on iOS Safari. Not any version. Ever. Apple only allows Safari on iOS. Therefore, any application that would like to do streaming will have to be native on iOS. Will have to pay Apple a 30% tax. Will have to live with Apple's approval and release schedules.
Apple has allowed Safari to stagnate in significant areas that would permit web apps to compete with native apps. This isn't another iOS vs Android flame war. It's more an indictment of Apple's development priorities on the mobile browser.
I saw that point yeah, sorry i missed mentioning it, but in my opinion, this is not even closely a reason to compare iOS to android, that's basic browser limitation, even though it's pretty recent on android, and your link marks it as "partial support", I wouldn't see it from a developer point of view nor from an end user point of view.
He was even comparing iOS to an old android phone, which definitely didn't support it either way and wouldn't even be updatable to support those new features.. and I wouldn't call a browser that doesn't WebRTC as a less capable one.
There is only one rendering engine on iOS. Apple TOS prohibits all other rendering engines. Chrome uses Safari/webkit rendering engine to render the page.
The general "Safari is the new IE" meme comes down to Apple having different priorities than other browser vendors (notably Google) when adding features. Right now the complaints tend to center on Service Workers and WebGL, but there are quite a few browser technologies in which Safari support lags.
The things Apple priorities -- battery life and security, for instance -- don't mean much to most developers who would prefer to be able to use <insert sparkling new web tech here> without worrying about shims, and so on. Problem is, you can't quote that "there are 1.5 billion Android users out there" with this in mind and keep a straight face. A huge proportion of those users are NOT using a browser this group wants to target.
> Thank god apple no longer allows that, how do you expect a tiny screen to have popups and switch web browser views when you click links ? this is a very bad UX.
I don't think you realize what he's talking about. Any mobile app has the ability to open links either sending them to the default browser or using a webview overlay. How is not being able to open any links at all a better user experience?
1-You're wrong, any app can do that on iOS/Android. who says that you can't open links from an iOS app ?
2-He was specifically talking about webapps in "standalone" mode, he specifically mentioned using `target="_blank"`. that kind of behavior does not belong in mobile environments, actually i personally disallow that on my computer too, but that's personal choice.
>Both iOS and android have fully capable web browsers, I'm not sure what's missing here ?
I think at that point he was referring to the initial appeal of the iphone, when th efirst one was released. there was no Android and no comparable device existent at the time.
>Thank god apple no longer allows that, how do you expect a tiny screen to have popups and switch web browser views when you click links ? this is a very bad UX.
What kind of phone are you using? most things got screens so big that they don't fit into my pocket anymore.
>I'm not here to judge your decisions or why you did it that way, but IMHO a chat product doesn't really belong in a "web browser"
Rocket.chat does exactly that and it is fantastic. Other webapps as well. The key feature being that you can chat on any browser, and using for example electron (the engine based on chrome, also used by the atom editor) you can easily build apps for every platform. And if you add features, they are added everywhere at the same time without a problem
>I think at that point he was referring to the initial appeal of the iphone, when th efirst one was released. there was no Android and no comparable device existent at the time.
True, but don't forget that the first iPhone was an expensive piece of nothing really, we had no app store nor sdks
>What kind of phone are you using? most things got screens so big that they don't fit into my pocket anymore.
I come from iPhone 3Gs->4->4s->5->6->6s->LG G4, I can say that it's a HUGE screen with bigger resolution than my desktop, but what i meant was the total size of the screen in physical size, i don't want no friggin popups and many windows in a 5" screen
>Rocket.chat does exactly that and it is fantastic. Other webapps as well. The key feature being that you can chat on any browser, and using for example electron (the engine based on chrome, also used by the atom editor) you can easily build apps for every platform. And if you add features, they are added everywhere at the same time without a problem
Ofcourse there are tons of good examples out there, I'm explaining my personal point of view when it comes to web browsers and doing lots of in it that that it was never intended for. I'm fine if you just rename it from web browser to "JS App Container" or whatever, but to me a web browser is just a place to browse pages
The context of this discussion is wanting to make the mobile browser a suitable platform for development of all apps similar to what has happened in the desktop browser. One of the reasons for this is that the web is one of the few truly open platforms. That it doesn't fit your opinions about what belongs in a web browser is not very interesting, especially since you're not giving any reason why you think some apps should not be in the browser.
>> I’m talking about stuff that QA should have caught, stuff that if anybody at Apple was actually building ? apps this way would have noticed before they released.
> A: They do pass QA, that's why features are removed
Even if QA catches stuff, it frequently gets ignored by developers and product managers who don't want anything holding up the ship date.
If the software gets frequent updates, this becomes the norm. Bug fixes come in future development cycles, not when they are found.
QA is the least powerful group in any software engineering setup so it's amusing that consumers think of them as God-like powerful creatures who can hold up releases.
I wonder how something like http://spritzinc.com would work for a dyslexic person ?
It basically gives you a single word at a time to read, would that make it easier for a dyslexic person to read bigger text if it was split into smaller one word chunks ?
