[HN Gopher] The End of Localhost
___________________________________________________________________
The End of Localhost
Author : swyx
Score : 87 points
Date : 2022-06-08 16:26 UTC (6 hours ago)
(HTM) web link (dx.tips)
(TXT) w3m dump (dx.tips)
| ary wrote:
| This is a ham-fisted attempt to get attention using controversy,
| and the arguments are so weak they can't even make me mad.
|
| Computing of any kind (including software development) moves
| around all the time. Sometimes it's more economical to do
| something with a bunch of servers over the internet, but less
| privacy preserving. Then user devices become more capable and
| it's suddenly possible to do everything you need on device and
| the platform(s) you're targeting all have enough lowest-common-
| denominator support to make it feasible. On, and on, and on.
|
| This "article" boils down to a myopic view of the industry that
| is almost solely supported by the solutions very large
| development teams have had to come up with to handle their human
| scaling issues.
| dogleash wrote:
| Arguing this point is all downstream from the fact software
| complexity has turned our general purpose machines away from
| general purpose use.
|
| Going with the path of least resistance is fine, often a
| commendable decision. Water flowing over rock can carve a
| canyon. But arguing that the canyon shape is where the river
| ought to be? Not for me.
| bbertelsen wrote:
| Agree, 100%. I was about to comment that this must be a jest -
| but aiming for controversy is surely the more accurate
| interpretation.
| daveloyall wrote:
| Alternative interpretation: the author is having a stroke.
| See how they miscategorized the "soul-stifling metaverse"
| tweet as "extremely positive". ...That's not what the tweet
| is saying... :)
| ur-whale wrote:
| The solution to many of the problem outlined in the article is
| not to move your work env. to the cloud (which has a boatload of
| problems in itself) but rather to be able to transparently
| install a perfect localhost copy of the environment the software
| you're building will run in, via - whatever - containers, vm's ,
| etc...
| viraptor wrote:
| That's my understanding too. The article mentions:
|
| > most of these items enable (even require) you to run things
| "live" on the cloud, not localhost
|
| But they really don't. If having them in the cloud helps you,
| you can replicate the experience by running that service
| locally.
| doctor_eval wrote:
| "Treat your engineering team like cattle, not pets"
| eatonphil wrote:
| I don't agree with this idea at all, at least not about using
| high-level cloud services as your development portal. But I do do
| almost all of my development in a server in Canada (I'm in NYC,
| though latency while traveling in Korea right now is worse). I
| control the server though.
| aenis wrote:
| This is ignoring the speed of light cap. Its not going to be
| possible to keep all those increasingly complex, distributed
| systems in sync with low latency. Its not going to be possible to
| instantly run a series of tests that depend on each other if they
| run somewhere 10ms away. Not to mention all of this is energy
| inefficient. I am all for productity gains but this is just
| nonsense.
| ranger207 wrote:
| I am currently (literally waiting on a EC2 Image Builder pipeline
| to complete as I write this) rewriting our dev VM to work on EC2
| rather than VirtualBox on our MacBooks. I'm doing this for two
| big reasons: One, the VM won't run well on future Macs. We're
| using Intel MacBooks on Big Sur because there's a bad interaction
| between Monterey and the VirtualBox kext that I can't figure out;
| and because making our VMs work across Intel and ARM would
| require a rewrite. Second, and more importantly, debugging why
| the VM isn't working on someone's laptop is a massive pain. My
| goal in moving the VM to the cloud is to reduce the surface of
| things that I have to troubleshoot. If ssh works on your laptop
| then (the hope is) I don't need to mess with your laptop any
| more. If the VM breaks, then when I fix it it'll be fixed for
| everyone at once. Believe me, that's not the case with the local
| dev VM despite the entire thing being scripts in a git repo.
|
| I'm trying my best to keep the new dev experience as painless as
| possible, but at the same time, moving the VM to work in a
| consistent and stable environment _also_ improves the dev
| experience along with my operational experience. It 'd be
| fantastic if we could run everything locally and nothing ever
| broke and everything that worked on my machine worked on prod
| too, but that's simply not the case
| ravenstine wrote:
| > Github "left our macOS model behind and moved to Codespaces for
| the majority of GitHub.com development".
|
| Yikes. I wasn't planning on working at GitHub, but I definitely
| wouldn't if that quote is genuine.
|
| Imagine actually being forced to use VS Code to do your work. I
| love VS Code, but it seems wrong to center the team's workflow
| around it. I guess you're screwed if you want to use Vim or
| Sublime?
|
| _" Oh, but there's plugins for that!"_, I can hear someone say.
|
| Yeah, f--- that sh--.
|
| And after all, who's to say that GitHub Codespaces won't someday
| drop VS Code when it's no longer in vogue? GitHub Classroom
| touted its Repl.it integration and then deprecated it almost
| immediately without an equivalent alternative (just use VS Code
| bruh), so it's not that farfetched.
| easton wrote:
| They covered that in the original blog post, as a ton of their
| internal devs liked their current setup. They ended up writing
| a little command line utility that would let you SSH into your
| codespace (spinning it up if necessary), so you could use
| whatever editor you want (including JetBrains IDEs now that
| they have good SSH support).
|
| https://github.blog/2021-08-11-githubs-engineering-team-move...
| (and if you want to try it, I think it's "gh cs ssh" in the
| github cli)
| thebean11 wrote:
| The "run the whole dev environment in the cloud" part actually
| sounds pretty nice. 10 seconds to have everything running?? And
| I assume you can switch between multiple environments you have
| saved, tied to branches? That's pretty sweet and opens up tons
| of opportunity for server side build caching to speed things up
| (don't need to compile the packages you aren't modifying).
|
| Is VS Code actually required, or is there some way you can edit
| source code locally then push to codespaces to actually run it?
| gscho wrote:
| Emacs and vim are supported!
| thebean11 wrote:
| What about JetBrains IDEs though? What if I want to run
| some one-off script on my local terminal that's interacting
| with source code files? Emacs and vim plugins don't go far
| enough IMO, it needs to fully support the local filesystem.
| simonw wrote:
| Can JetBrains IDE open and edit files over SSH? If so, it
| will work with Codespaces.
| danielvaughn wrote:
| I agree that being literally forced to use Codespaces is kind
| of shitty.
|
| On the other hand, establishing code consistency is important,
| and it all depends on your editor's linter/prettier. They have
| to produce the same output, and even managing that within the
| same editor is difficult because you might have different
| versions on each dev machine, or different user settings. Doing
| so across editors is even more difficult.
| gscho wrote:
| There's also the benefit of "dog fooding" their own product
| that they're selling to customers.
| thebean11 wrote:
| Prettier / linter can just be run in a git hook and verified
| in a GitHub action / CD step though. Prettier config should
| be committed to the repo itself, then let devs decide how
| they want to apply it to their workflow (and prevent them
| from merging otherwise).
| ramesh31 wrote:
| Localhost will always be free, and the cloud will always have a
| cost. For that reason alone, localhost isn't going anywhere.
| mnd999 wrote:
| Which is why it appeals to GitHub / Microsoft. Now you have to
| pay them for something you used to do for free.
| kaetemi wrote:
| Yep. Most of the people I know don't want to pay subscription
| fees for cloud services, when their own desktops are powerful
| enough to run what they're working on.
|
| Just automate localhost development environment deployment.
| satyrnein wrote:
| Localhost isn't free, we buy more expensive laptops for
| developers than any other teams.
| ozim wrote:
| I think article is arguing that localhost still has cost when
| onboarding and maintenance cost that is not really that visible
| because maintenance happen while devs are doing other task -
| but usually it is included in some task to setup some config.
|
| So I would agree localhost can be basically free, only that
| company has to keep developers in-house and not burn through 10
| juniors each quarter.
|
| If company wants to burn through people like Amazon in
| warehouses then having cloud dev-env is way to go.
| hexo wrote:
| Another thing designed to take my money. Nothing else. Won't use
| :)
| rglover wrote:
| No. This is the absolute wrong direction.
|
| In effect, you're giving a third-party absolute control over your
| code and your ability to work on it. You're also disconnecting
| the developer's mental model of how all of this stuff works
| (arguably why there's so much bad code floating around).
| Eventually, that will devolve to people not knowing how any of
| this works and the industry will collapse.
|
| It's an abstract line of argumentation related to this, but
| Jonathan Blow nailed it on this idea a few years back:
| https://www.youtube.com/watch?v=pW-SOdj4Kkk
| WorldPeas wrote:
| I'd do it if said platform was FOSS and self-hosted, but until
| then, I'm staying in fort localhost
| c0balt wrote:
| Same here, maybe GitLabs "web IDE" will one day support this
| by, e.g., pairing a vm or container to each session, and
| adding extensibility. Though given the massive monster that
| GitLab is already it might take some time (and $).
| 1shooner wrote:
| Gitpod would meet those requirements:
|
| https://www.gitpod.io/blog/opensource
| numpad0 wrote:
| Article claims the practice is adopted by Google, Facebook,
| Tesla, Palantir, Shopify, GitHub. That tells a lot!
| smoochy wrote:
| I was reading your comment and thought of Jonathan Blow's talk.
| Without even clicking the link, let me guess, that's from
| Moscow's 2019 conference?
|
| EDIT: yes, it is. He has a very important point there. I
| recently went on Twitch to see what young devs where coding.
| One (rather smart, I must say) young lady was creating a simple
| sign in/sign up page, but there's a twist: with React. Upon me
| asking, why wouldn't she just code it in plain HTML, she
| responded with a question: "but how would it connect to the
| API?". So there you go, ladies and gentlemen. I don't really
| know what to do about it, but I don't believe we're a bunch of
| old men yelling at a cloud (quite literally - AT A CLOUD),
| especially that I don't think we're that old.
| rolisz wrote:
| I had a similar experience with my sister in law who is
| getting her programming degree this month. When I asked her
| what was her final project and some details about it, she
| told me the entry point to her frontend was Angular. When
| asked how it was served and how it got to the browser, all i
| got was confused looks. When I showed her that the first
| thing that gets to the browser is an HTML file that then
| loads Angular and her application, her mind was blown.
| rco8786 wrote:
| I had a similar experience with a family member. When I
| asked them how their keyboard strokes appeared on the
| screen, all I got was confused looks. When I showed them
| that the first thing that happens is a hardware interrupt,
| her mind was blown.
|
| Seriously, it's okay that people don't know the ins and
| outs of every little detail. Abstractions are useful, until
| they're not. And then when they're not, you go figure out
| the level below.
|
| Even the most advanced, most skilled front-end devs spend
| 99.99% of their time not caring that the browser loads an
| HTML page.
| Mordisquitos wrote:
| I think your analogy would be valid if the previous
| commenter had, for example, asked their sister-in-law how
| the browser interprets the JavaScript it receives, or how
| it builds the display from the DOM. Now _that_ would be
| asking about irrelevant and unnecessary levels of detail
| which are best abstracted away. However, knowing that the
| process starts with the browser receiving HTML over HTTP
| is essential to understand what 's going on, even if you
| know nothing about the details.
|
| If I may, a truly similar experience regarding keyboards
| would be this:
|
| _I had a similar experience with a coworker. When I
| asked him how the code that he types appears on the IDE
| on his screen and not on that of any of our colleagues '
| screens, all I got was confused looks. When I showed him
| that his keyboard is wirelessly connected only to his
| computer, which runs the IDE, and his computer is then
| specifically connected to his own monitor via a cable,
| his mind was blown._
| rco8786 wrote:
| It was just a random example, you can literally pick any
| level in any number of abstraction stacks that exist and
| make the same analogy.
|
| Sometimes it becomes necessary to know how the level
| below works. That doesn't mean it's a requirement to be
| affective at the level above.
| Guvante wrote:
| I would categorize things as "does someone on the team
| need to know this":
|
| * Why does a key appear on the screen when I push a
| button on my keyboard: no
|
| * How is an HTTPS connection created: generally no
|
| * How is the JavaScript library deployed: 100% yes
|
| You might be able to throw something together that works
| without understanding that it is a JavaScript library
| with a bootstrap HTML page but if no one on your team
| understand that you will eventually need to find someone
| that does to solve a problem.
| Kalium wrote:
| > * How is an HTTPS connection created: generally no
|
| I would think that people doing web development probably
| benefit from a working knowledge of DNS, TLS, and PKI.
|
| Without those, I would expect a lot of readily avoidable
| problems with HTTPS.
| Calavar wrote:
| > That doesn't mean it's a requirement to be affective at
| the level above.
|
| Not necessarily, but it _did_ have a material effect in
| the original example. A web developer drug in a complex,
| unnecessary framework because she didn 't realize that
| HTML forms have the ability to submit post and get data
| natively.
|
| To me that's like a civil engineer building a suspension
| bridge over a tiny creek because they never heard of an
| arch design.
| [deleted]
| rglover wrote:
| Yup
| chrisweekly wrote:
| Yeah; knowing about the HTML form tag apparently qualifies
| you as a senior web dev.
| onion2k wrote:
| Considering how many web developers get that particular tag
| wrong I'm not sure that's actually as unreasonable as it
| first appears. The number of forms out there on the web
| that are really just used as a way to group collections of
| input elements, with no consideration for an action, a
| method, browser native validation rules, fieldsets, a
| legend, etc makes me wonder if people actually know HTML at
| all. Every React, Vue, etc form I look at the source for
| gathers up input into state and then submits it with a
| fetch, replicating, but also often breaking, the
| accessibility and functionality built into the browser.
|
| So yes, maybe being able to implement a form tag in HTML
| _is_ the mark of a senior dev.
| corrral wrote:
| I'm very much on the "this shit's too complicated, we
| should fix whatever's making us not use the standard
| features and tools instead of piling this garbage on top"
| train, but I think a valid defense of doing things in
| Javascript that could be done in HTML is that, as soon as
| you need to do _any_ e.g. form validation in JS, it may
| be simpler to just do _all_ of it there.
|
| The accessibility issue is, of course, a solid counter-
| argument to running too far with that line of reasoning,
| and is part of why I'd much rather we put 1/10 the effort
| we do to constantly re-implementing basic HTML features
| into unfucking HTML standardization so we can finally
| have elements good-enough that we don't need to pile JS
| on top to get what ought to be built-in functionality.
| But, that's a whole different skillset from programming,
| and requires far more organization than thousands of devs
| all independently, or in small teams, working on yet
| another NIH version of an image upload input. :-/
| anyfoo wrote:
| I see web development is still trying to make something
| fundamentally ill-suited for its task work by stacking
| shoddy layer after shoddy layer on top of it, just like
| it did when I left web development 10 years ago and went
| back to system programming.
|
| System programming also has its warts, but at least most
| of the time you don't feel like you're working against
| the machine.
| forty wrote:
| Not knowing about it can also qualify you as a very senior
| dev (though not very up to date with recent improvements)
| as the form tag was apparently added to the (then informal)
| HTML format around 1994 ;)
| rglover wrote:
| > I don't really know what to do about it, but I don't
| believe we're a bunch of old men yelling at a cloud (quite
| literally - AT A CLOUD), especially that I don't think we're
| that old.
|
| I'm working on it: https://github.com/cheatcode/joystick.
|
| The tl;dr is that I'm offering a full-stack framework that
| takes advantage of vanilla JavaScript and HTML in a front-end
| framework combined with a plain ol' HTTP back-end using
| Node.js. The APIs abstract just enough to make you productive
| but not so much that you can't reason about how it'd work
| _without_ the framework.
|
| The long shot of the project being to keep the mental model
| of "how the web works" intact while reducing the burden of
| doing everything from scratch.
| c0balt wrote:
| Your project looks interesting. Do you plan Typescript
| support with stubs vor smth similar?
| rglover wrote:
| Thanks. If I do, it won't be supported beyond the
| compiler/build tool (no official recommendation of using
| it w/ limited support).
|
| It's an unpopular opinion, but I view TypeScript in the
| same light as I do the OPs assertion about cloud-only
| development. It's adding yet-another-layer that has some
| merits but often leads to overcomplicated messes that
| reduce productivity/add confusion.
|
| I'd rather petition for some sort of structs/arg typing
| to be included in ECMAScript proper (in a similar fashion
| as to what happened with a lot of Jon Resig's jQuery DOM
| selection APIs making their way into ES6).
| heavyset_go wrote:
| As to you last point, there are proposals to bring typing
| to ECMAScript right now.
| com2kid wrote:
| The funny bit being react uses regular browser APIs for
| network requests! Nothing was even gained, just call fetch!
| kevlened wrote:
| True! Though the funny bit is you don't need an API at all
| (at least not a json-driven one). A form post is even
| simpler.
| bryanrasmussen wrote:
| What if the API she wants to call doesn't have a form
| based version?
|
| Suddenly she needs to change stuff on both backend and
| frontend, and she might only be allowed to touch one of
| those ends.
| mwcampbell wrote:
| I think the best solution to this is to eliminate the
| division of labor between back-end and front-end, for the
| majority of applications that don't actually require deep
| specialization in either. As DHH put it, integrated
| systems for integrated programmers [1].
|
| [1]: https://m.signalvnoise.com/integrated-systems-for-
| integrated...
| shkkmo wrote:
| I think this is a question about becoming dependant on
| abstraction rather than where the abstraction is run.
|
| I don't think that being "in the cloud" makes abstraction
| that much more pronounced. You can have manually configure
| dev VMs in the cloud or automatically configured dev VMs
| locally, the later will probably use more abstraction.
| MikeDelta wrote:
| One argument that I hear is that all these abstractions allow
| the developer to focus on delivering products and not worrying
| about the nuts and bolts of the underlying system, but in my
| experience the best and most efficient developers have been the
| ones who know how the systems work.
| rco8786 wrote:
| Those things are not mutually exclusive though, at all
| MikeDelta wrote:
| They are not indeed, just sharing my anecdata that the best
| ones I have come across happen to know much more about the
| details.
|
| I am sure one can find good and efficient devs that know
| very little about the underlying system and are very
| capable of using the available abstractions and frameworks.
| I just happen to find the first group better.
| HideousKojima wrote:
| Basically the same idea as this article about how current
| college students in CS programs don't really have any
| conception of what a filesystem is:
| https://www.theverge.com/22684730/students-file-folder-direc...
|
| At least Android and iOS taking over the consumer computing
| world has given me job security until I retire!
| brobdingnagians wrote:
| You can make development more complex to match production and
| then layer more and more complexity on to to make it convenient
| (and brittle) or you could simplify production so that it is
| straightforward, replicable, and bulletproof. I know which one I
| prefer. It would be better to simplify and streamline the system
| than to layer abstraction upon abstraction is a bizarrely
| escalating tower that needs more complex "fixes" to counter the
| complexity, which increases complexity for the next round.
| dottedmag wrote:
| > But surely you can see that the latency question is a question
| of letting the Moore's law equivalent of cloud commoditizing
| infrastructure take its course. If it's not good enough today,
| then wait 5 years and check back again.
|
| Wait, speed of light also improves exponentially?
| rajko_rad wrote:
| hahah isn't the solution to this just edge computing? e.g.
| cloudflare workers, fly.io, or seaplane?
|
| Can't solve the speed of light, but can certainly reduce the
| distance...
|
| Like it or not, enabling many collaborative apps already
| requires solving this today, lots of work in that direction!
| pantulis wrote:
| Speed of light is negligible here. Latencies from your computer
| to its connected display are measured in ms, the same order of
| magnitude to move bits across the ocean. It's "only" a matter
| of moving more bits at the same time across the networking
| infrastructure as the cloud gaming industry is doing.
| IHLayman wrote:
| I work for a Japanese company from the east coast, and I can
| tell you from personal experience that latency matters and
| that you can't beat the speed of light. 1 light millisecond
| is about 186 miles. Communicate with a server halfway around
| the globe and you have a 277ms round trip. On a reaction test
| online my reaction time is 243ms, but I am pretty slow at
| reactions. My typing speed is about 70wpm (about 350cpm or a
| character every 100-150ms). Trust me when I say that people
| notice slowdown when response is >100ms.
|
| So ok, you'd think that 9300 miles is close enough (50 light-
| ms each way), but even that can show lag because your
| infrastructure needs to react to whatever you are typing
| (even Vim nowadays will connect to a language server to do
| tab completion and symbol lookups) and then send you a
| legitimate response.
|
| And all of this is ignoring the most obvious arguments:
|
| * Your local silicon is fast enough to do development and has
| been for 10 years now. Stop using a bloated IDE.
|
| * If you production environment is so different than your
| local simulation of that environment, then you have bigger
| problems.
|
| * Why rent your compute per month when you can own your
| compute and use it however the hell you want to use it?
| FredPret wrote:
| I see you haven't clicked on a GUI on a server a continent or
| two away
| azeirah wrote:
| I tried Jetbrains remote workstations with Jetbrains space.
|
| I had a pretty reliable ~150ms connection. It sucked SO BAD.
|
| 150ms + input latency before I see a response? It's a
| horrendous experience. Ask any pro gamer what they think
| about gaming with a ping higher than 20-30. Same thing for
| development.
| scottlamb wrote:
| > 150ms + input latency before I see a response? It's a
| horrendous experience.
|
| Definitely, but there are ways to mitigate that:
|
| * Better design. With VS Code Remote or Google Cider, the
| code is stored remotely and the language server runs
| remotely (so there's lag before the completion pull-down
| appears) but the UI is local. Characters you type should
| appear with no round trip required. That seems like table
| stakes for a good remote development environment in the
| world the author describes. You can also imagine some
| prefetching of near-future likely completions [edit to
| clarify: e.g. prefetch the completion menus that will
| appear if the user starts typing any of the locals in
| scope, including not only the names of the locals but also
| their methods] so that latency is hidden too. For CLI
| stuff, mosh predicts the characters you type will echo and
| corrects if not. etc.
|
| * Closer datacenters. Typical RTT from Los Angeles to New
| York is ~66 ms. 150 ms is far!
|
| * Lower index of refraction. Instead of traditional fiber,
| hollow-core fiber or bouncing off LEO satellites like
| Starlink. Not going to happen universally by 2030, but it
| will happen some day.
| rad_gruchalski wrote:
| I recently develop on cluster.local and I'm happy enough :)
|
| Regarding the article: what if the ,,cloud company" decides to
| suspend your account for ,,reasons"?
| wooptoo wrote:
| Yeah, no.
|
| I've seriously considered moving back to Sublime Text because
| VSCode has become annoyingly slow for me (like waiting for text
| to appear). And also the Python extension auto-complete only
| works some of the times lately. Now imagine further bogging it
| down by running it in the cloud.
| trasz wrote:
| I'd argue the exact opposite: with each year the cloud makes less
| and less technical sense. Local computing power, storage, and
| networking are getting cheaper all the time, while cloud services
| really aren't, and won't because of their business model. Cloud
| is also risky for security, privacy, and business (hard
| dependency on a single vendor) reasons.
| ClumsyPilot wrote:
| > Fast gigabit internet is cheap and everywhere
|
| Check your privilidge!
|
| Generally our industry is phemomenally irresponsible, there will
| be some life-critical service that gets built with this attitude,
| and no-one will realise untill some shit hits the fan - whether
| it's a power cut or an internet cable being cut but a digger or
| the AWS datacenter burning down - and then people will die.
| jacquesm wrote:
| I think we're already there. A hospital that loses it's
| internet connection would have a hard time functioning and
| depending on the length of the outage it may very well cause
| people to die. Between scheduling, medication conflicts,
| diagnostic tools, EPD exchange, cloud connected medical gear
| and so on this is no longer a theoretical thing.
| scottlamb wrote:
| > > Fast gigabit internet is cheap and everywhere
|
| > Check your privilidge!
|
| Umm, what? This is part of "the ultimate developer experience
| wishlist for the average rich-country developer in 2030", not a
| statement expected to be universally true in 2022. I think it's
| wildly overoptimistic, but "check your privilege" doesn't seem
| like an appropriate response to optimism.
|
| > Generally our industry is phemomenally irresponsible, there
| will be some life-critical service that gets built with this
| attitude, and no-one will realise untill some shit hits the fan
| - whether it's a power cut or an internet cable being cut but a
| digger or the AWS datacenter burning down - and then people
| will die.
|
| The "average rich-country developer" doesn't build life-
| critical services. If someone extends the author's techniques
| to a domain where they're inappropriate, that's on them.
| twblalock wrote:
| There are a lot of weak overextended arguments in this piece
| which reduce its credibility and persuasiveness.
|
| One example: just don't code on airplanes.
|
| Or how about this one:
|
| > To argue against localhost eventually going the way of the Dodo
| is to do the developer equivalent of asserting that most people
| want to run their own generators or grow their own food.
|
| Come on. That's not a serious attempt to persuade. It's
| practically a rant.
| [deleted]
| yjftsjthsd-h wrote:
| > asserting that most people want to run their own generators
|
| Also, lots of people specifically have generators to cover when
| the grid fails them. Like, I'm actually okay with the claim,
| _because that 's an argument in favor of local development_.
| doctor_eval wrote:
| Yeah - my new house is about to get covered in solar panels,
| and I can't wait!
| no-s wrote:
| Futurists extend trends, but innovation defies trends. So this
| article is about futurism, not innovation. I would believe the
| blurring of cloud, edge, and localhost more than this. I think
| it's reasonable to believe network splits (physical or political
| or economic) will always be with us and thus the need to support
| disconnected computing will
| continue...Serverless/FunctionsAsAService could work this way.
| So? Maybe provisioning to an edge is a reasonable thing.
|
| The article mentions edge workers; the edge worker can be at
| localhost. The provisioning system can incorporate localhost. But
| yeah, localhost becomes livestock instead of pets...local
| computing power will still be a thing. Anything that needs ultra-
| low-latency or disconnection tolerance will be reified to task,
| like smartphones or smart munitions, or developer tools, or
| spaceship computers...not really too different from what we have
| now.
| juancn wrote:
| Lightspeed is still an issue. I've done remote development and it
| sucks. Even with gigabit connections, ~150ms latency can kill
| you.
|
| Maybe you can keep the editor local, and have it hide the latency
| for you, but debugging?
|
| With anything over a few ms latency remote debugging is
| impossible (or at least extremely annoying). Step over? Wait a
| few seconds to a minute until the debugger issues one call to get
| each variable in scope and all the other goodies.
|
| Debuggers assume local environments, we would need new tooling
| that's latency aware to handle this, in every major language and
| platform.
|
| I don't see this being good enough for serious dev work in a long
| time. It will work for some niches though, specially if you're
| close enough to the datacenter hosting your infrastructure.
|
| In a sense, a local git repo with an IDE, and a cloud
| unit/integration testing pipeline is as close as we get now, but
| every once in a while, you need to run at least a little bit
| locally to be productive.
| zaptrem wrote:
| Even with a crappy DSL connection I haven't routinely seen
| >70ms latency for years. Modern cable/fiber/LTE/NR connections
| are all well under 50ms. Even then, we have realtime games with
| lag compensation that make that connection instant. Your
| problem sounds like a badly written app, not a tech limitation.
| doctor_eval wrote:
| So now we have to build real-time lag compensation into our
| dev tools?
| sph wrote:
| I'm in London, my fancy iPhone on 4G is fast enough, yet it
| averages 100ms latency, as measured by ping.
|
| Explain that.
| tomc1985 wrote:
| Where you live, sure. But I can drive just a couple hours
| north of San Francisco and lose all cellular connectivity,
| entirely. In fact I am doing just that tonight and my friend
| and I have made contingency plans for meeting up at a
| festival going on in the mountains off the 101, where we
| expect to have no cell service.
|
| I really wish people would set aside their "well it's always
| worked for me, surely it must work for everyone" attitude,
| because it is tragically and obnoxiously false.
| Sohcahtoa82 wrote:
| Latency is affected more by geographical location than your
| local internet connection.
|
| If you're in San Francisco connecting to a server in London,
| it's a physical impossibility to get under ~60 ms, and that's
| assuming a direct signal going across the surface of the
| planet at the speed of light. In reality, it's not direct,
| and there will be at least a couple dozen routers between.
| sophacles wrote:
| What definition of latency are you using here?
| falcolas wrote:
| > connections are all well under 50ms
|
| This depends entirely upon where you're connecting to, and
| from. For example, I can't connect to us-east-1 servers with
| under 50ms of latency, because I'm out in the rural west, and
| my connections run a thousand miles south before getting on a
| good east/west backbone. Spikes are not uncommon.
|
| > we have realtime games with lag compensation that make that
| connection instant
|
| When the prediction algorithms are correct. When they're not,
| you start seeing some uncanny behavior that you can't predict
| or compensate for (dead-on shots missing, actions being
| rolled back, etc).
| treis wrote:
| >Maybe you can keep the editor local, and have it hide the
| latency for you, but debugging?
|
| >With anything over a few ms latency remote debugging is
| impossible (or at least extremely annoying). Step over? Wait a
| few seconds to a minute until the debugger issues one call to
| get each variable in scope and all the other goodies.
|
| Feel like this is similar to how Dropbox started. In that, the
| reasons given for why it wouldn't work were based on how
| previous solutions sucked. So yeah, if your debugger takes a
| minute to work then it'd suck. But what if it didn't?
| pjmlp wrote:
| I have done enough debugging using graphical debuggers on X
| Windows sessions.
|
| It is so ironic to see the pendulum swing back to how I used to
| code in UNIX environments 30 years ago, while being told it is
| impossible to have worked like that.
|
| Not only that, using development VMs has been a constant for me
| since 2011, either via Citrix or RDP.
| eatonphil wrote:
| > Not only that, using development VMs has been a constant
| for me since 2011, either via Citrix or RDP.
|
| I do most development out of a baremetal hosted server in
| Canada. But I think the original article is talking more
| about using cloud services like cloud editors, cloud
| databases, rather than using a VM or server hosted by someone
| else where you have root access and run all your stuff
| (editor, databases, etc.) _there_.
| jacquesm wrote:
| Plenty of secure dev environments work like that.
| discreteevent wrote:
| Debugging won't be a problem if the dev environment is on the
| cloud. 100ms latency works fine with Remote Desktop Protocol
| when typing. However, I don't agree with the article for other
| reasons.
| Macha wrote:
| > 100ms latency works fine with Remote Desktop Protocol when
| typing.
|
| This may be the crux of the issue. I've been confused when
| proponents of the idea indicate the experience is fine or
| preferable to local use as if the latency wasn't there.
|
| I don't think we can agree if one side thinks 100ms latency
| when _typing_ is ok. Meanwhile other people are giving some
| of the new terminals flac for having 40ms vs 10ms latency
| (https://danluu.com/term-latency/). I tend to agree with the
| second group more.
| viraptor wrote:
| It really doesn't work well. As in, people who touch type are
| slowed down if there's 100ms delay. Moving the cursor around
| is also awkward, because you're often pressing a key multiple
| times per second or rely on repeat rate which does the same.
|
| I do it once a week or so (for a very short time) and would
| rage quit any job requiring this every day.
| spc476 wrote:
| I have to fill in a "time card" each week. The old system
| was a simple web page that I could navigate primarily via
| keyboard, tabbing from field to field. I _think_ it was a
| company-developed web app, so the people who made it also
| had to use it. Then that was scrapped for an "enterprise
| solution."
|
| This is is also a web app, but it's slow. You have to click
| in a field, watch as the selection menus are filled in in a
| second or two (as the gigabytes of Javascript pulls data in
| via a database query in real time), and if it's a text
| field, you have to click in it, type real slowly, and click
| out of it. Don't tab to the next field because the tab key
| doesn't work as expected. What used to take a few seconds
| to fill out a days' worth of time now takes a few minutes.
| The C-suite, who bought into this crap, don't have to use
| it because that's what secretaries^Wassistants are for.
|
| If this is the future of computing, I want off at the next
| stop.
| habitue wrote:
| dev/prod divergence isn't the reason to do dev in the cloud. The
| reason you do dev in the cloud is dev/other-dev divergence.
|
| I'm a big fan of doing dev in the cloud (at least for work, no
| way I'm doing that for personal projects). Currently we use
| Gitpod, it works pretty well. Spinning up new people is easy, and
| so is keeping everyone's environment up to date with each other.
|
| But even in the bright shiny future of 2030 the dev environment
| is always going to differ from the production environment
| because... developers need a bunch of stuff in their image that
| you don't want installed in production.
| LinuxBender wrote:
| _All the Cloud 's A Staging Env, and All the Laptops Merely
| Clients_
|
| This fantasy has been pushed since at least 1996 but that really
| died off when mainframes were no longer the only option. Sure, my
| old Wyse terminal fits the bill but I have not powered that thing
| on since ... actually I don't remember where I left it. Cloud
| providers will always be a thing and local software daemons will
| always be a thing. There is a time and purpose for both.
|
| Anyway, I tried to convince some development teams to go this
| route some time ago and use Chromebooks with Citrix farms so that
| their work remains in a safe location. That idea died faster than
| I came up with it. There were entire teams that would have
| outright quit had I forced the issue. We did use that concept for
| some sensitive customer data debugging but never for development
| or staging.
|
| _General purpose computation on your own machine is probably
| going to be illegal in 20 years..._
|
| Some companies would love for us to believe that. Maybe some day
| politicians will be _lobbied_ into making _some_ services cloud-
| only. Unless their business model already fits being cloud-only I
| would expect such legislation to bankrupt some businesses or hurt
| them enough that the SEC or someone else that cares about tax
| revenue intervenes.
|
| Microsoft has been trying to move Windows in this direction, to
| require an internet connection and connectivity to their cloud
| and accounts on their public AD servers. The latest IBM/Redhat
| Fedora Beta hints at moving in this direction as well. I do not
| participate in such things but that is my personal preference.
| nerdponx wrote:
| The Wyse keyboards with Cherry mechanical switches are
| sometimes worth something. The keycaps are super cool too.
| throwaway787544 wrote:
| I've noticed that if developers can't run their code in some
| hand-crafted one-off buggy inconsistent mutable local
| environment, they freak. To the point that they're fine with
| using some proxy to a remote K8s cluster as long as their
| application code is executing locally. My guess is they fear a
| lack of control, and a local environment makes them feel safer,
| like they aren't stumbling in the dark trying to figure out how
| to make an app work.
|
| Most developers don't really understand the cloud at all, and
| that lack of understanding combined with their local env baggage
| is half the reason DevOps people are necessary. If devs adopted
| cloud native workflows, a lot of shit would be easier for
| everyone. It would even lead to better designs. Devs think the
| cloud works like their desktop, when really it's a radically
| different model for system design. I mean, there still devs who
| assume their app will use a filesystem to store data, lol!
| majewsky wrote:
| Poe's Law applies: I'm honestly not sure if you're being
| sincere or engaging in deliberate parody.
| nerdponx wrote:
| I just want to be able to test my code. I've seen software
| projects go fully into cloud-hosted microservices, without even
| a consideration of testing. It sucked.
| ClumsyPilot wrote:
| > Most developers don't really understand the cloud at all
|
| Most developers don't understand how their own computer works.
| gatvol wrote:
| Bad idea. This leads to vendor lock-in, propietary systems.
| Klonoar wrote:
| I think the author's got a kernel of an idea and does an
| absolutely horrible job outlining it, considering few here seem
| to be catching on.
|
| Localhost will likely never die for certain sectors of
| programming. There's a _significant_ chunk of stuff that doesn 't
| need to be custom localhost setups, though - and ultimately it
| can smooth out the differences between dev/production in teams
| where this is a stumbling block.
|
| You don't need localhost to be some server somewhere that kills
| your ability to work with an outage - stuff like StackBlitz
| (https://stackblitz.com) effectively uses WebAssembly to run e.g
| Node directly in the browser sandbox. This model is the first one
| that makes me think it's possible. You no longer have that
| dangling issue of "which of my NPM packages is going to try and
| steal from me" since it's walled off in a sandboxed environment
| that spins up faster than you can blink.
|
| The caveat to all of this is that we should fundamentally never
| let localhost die, as ceding total control to services to build
| on is a pretty bleak future. There's a good middle ground to find
| here though.
|
| A final aside: an article telling me _I 'm wrong_ for wanting to
| code while flying is a junk take.
| chazeon wrote:
| As a computational physics student, I am recently moving to fully
| embrace the model describing in the article. I work on multiple
| HPCs, and now I use a machine (m720q) as proxy that SSH onto HPCs
| and run code-server there. From my laptop, I just visit the
| website on this m720q machine, and everything is done via a
| browser. Besides code-server, I also run a JupyterLab instance on
| the machine because we are not allowed to run jupyter on HPC's
| login nodes. All scripting / terminal is now done through the
| code-server (similar to GitHub Codespace). Tailscale allows me to
| access this proxy server outside home.
|
| On embracing this this model avoids moving large files GB+ from
| remote to local machines via SFTP, and I can avoid typing SSH
| commands every time I go from home to school. Code-server allows
| me to run more things on HPCs instead of local machines.
| Previously I used VSCode Remote, the latency might interrupt the
| connection, and now with code-server this is no longer a problem.
| nathias wrote:
| are mainframes popular again?
| jaywalk wrote:
| > But I Need To Code on a Plane? Maybe stop flying so much. Or
| get a good audiobook and rest your eyes. Maybe even talk to your
| neighbor! (if they seem social)
|
| Get out of here. Airborne Internet access has gotten good enough
| that I spend most of my flight time RDP'd into my development
| machine over a VPN. It works surprisingly well, and other than
| occasional latency spikes I find the single, relatively small
| laptop screen and touchpad to be more of a hinderance than the
| Internet access.
| ravenstine wrote:
| I agree. I've both done Zoom calls and watched YouTube videos
| in HD over plane wifi. There's only one zone towards the end of
| my trips to the other side of the country where it stops
| working, but hopefully more dead zones will be patched over the
| next decade. Internet access makes all the difference in my
| ability to tolerate long flights.
| rajko_rad wrote:
| There should be good models already or emerging soon that
| support temporary local dev and then merging envs when
| connected back... that seems like the inevitable model unless
| I am missing something here?
| jrochkind1 wrote:
| As a developer who works in very small teams/orgs, though: Will
| you need a "devops" team of 10+ just to create and keep the
| cloud-hosted development environment working?
|
| Cause that's why I currently prefer avoiding even docker for my
| dev env.
| habitue wrote:
| This is what companies like Gitpod do, they are the devops
| team, and you just manage the dockerfile that determines what
| the dev environment looks like.
| satyrnein wrote:
| In the ideal case, you stamp them out using basically the same
| docker/terraform/etc you use for managing production.
| teeray wrote:
| Cloud development machines are great---secure, consistent, etc.
| ---right up until you have a cloud outage and your entire team's
| productivity goes to zero. That's "zero productivity" as in an
| elementary school snow day.
|
| Even when Github has gone down for hours, I've still managed to
| do code reviews with good old-fashioned `git format-patch` in
| chat.
| wyager wrote:
| > Fast gigabit internet is cheap and everywhere (5G or mesh wifi)
|
| I don't need to read farther than this; I am 98% certain that the
| rest of the article is hopium nonsense. "Mesh wifi" has never
| been and never will be the solution for any large-scale
| networking cost/performance issue.
| WesolyKubeczek wrote:
| Because the world is made of bandwidth and large cities and each
| ISP will gladly sell you a multigigabit pipe for peanuts, and
| there's 6G wireless with absolutely no outages whatsoever.
|
| Also everyone just works at FAANG or is not worth talking to.
|
| I have this weird idea of selling a globe where the only land is
| Bay Area. For $9,999.99 apiece. It's being reinforced by articles
| like this one.
| Existenceblinks wrote:
| Could be done with Erlang hot code reload with pull request in
| between.
| frizlab wrote:
| No thanks. I like having stuff on my machine.
| pantulis wrote:
| It's not a matter of personal preference if your work for
| someone else. This stuff is bound to happen in the years to
| come. Local development of course will still be possible but
| will become the minority in the global workforce.
| falcolas wrote:
| The company I work for has enough services that the entire
| stack can't be run locally anymore. But we have found ways to
| make it local development work regardless.
|
| And so will other companies, since it's a definite
| productivity boon.
| api wrote:
| Also no privacy at all, ever. Every single keystroke is watched.
| Everything you run is profiled. All your data is logged, scanned,
| probably stored forever, and probably data mined.
|
| It'll start at work of course but eventually the whole ecosystem
| will shift and it will no longer be possible to develop software
| without the cloud watching every single thing you do. Someone
| doesn't like what you're building? It will suddenly vanish and
| take all your work with it. Price goes up? Tough. Pay the rent or
| all your work vaporizes.
|
| This whole trend is deeply, distressingly dystopian. It's a total
| inversion and reputation of the whole concept of personal
| computing and everything associated with it, a return to the
| mainframe era but worse because big data and AI make mass
| surveillance and automatic control so easy.
|
| It's equally distressing that most developers don't even
| understand the trend enough to push back on it. They don't grasp
| the fact that the difficulty of local system administration and
| the general over-complication of everything is driving this, so
| they don't address any of those problems. In fact they keep
| making them worse. Development environments keep getting more and
| more complicated and fragile, making a move to a shared centrally
| managed cloud environment more and more tempting.
| muskmusk wrote:
| Yes and no.
|
| If everything needs 5 databases, 4 queues, 3 caches and all of
| this is written in 7 different languages, then yeah I guess cloud
| is the way to go.
|
| If you just shove shit into postgres and pull it out again using
| something like postgraphile then I don't think cloud does much
| for you.
|
| The Flipside of the "computers gets faster and faster"-argument
| is that more and more can be done on one machine.
|
| Compute supply is growing faster than demand. Today's apps are
| not that much more complex than the apps of 10 years ago, but
| computers are much faster. Human beings read and type at the same
| speed today than 10 years ago so I don't really see this changing
| massively.
|
| Obviously all the BigCos listed can't run on one machine, but a
| very large percentage of stuff can.
| mike_hearn wrote:
| Agree. A lot of the movement to try and develop everything
| inside Linux containers is driven by a few factors, none of
| which are particularly fundamental and which may see a reversal
| for unrelated reasons in future:
|
| 1. The insistence on doing UI exclusively via web browsers.
| They aren't particularly well suited to it and at some point
| competition for them may arise.
|
| 2. The insistence on using complicated proprietary cloud
| services to allow scalability, without actually doing any
| scalability calculations to justify it. A modern dedicated
| server is a staggering piece of kit. NVMe SSDs are game
| changers. You can scale a bog standard ordinary RDBMS setup to
| very large amounts of load without needing any special cloud
| databases at all, and it'll be easier to program. People don't
| realize this because they tend to think about scaling in binary
| terms: "it scales infinitely"/"it doesn't scale and that's
| bad". That sort of mental shortcut can be OK when money is
| free, but, well, we're entering a period where it may not be.
| The sort of engineers who can actually do load tests and figure
| out plausible maximum QPS for their load can pay for themselves
| quickly.
|
| 3. The fact that the only competition for Linux on the server
| side is cloud APIs and services, and Linux badly needs the
| competition.
|
| 4. The popularity of toolchains/languages with extremely weak
| portability layers and convoluted packaging systems. Java
| nailed this. Python, Ruby, Go ... not so much. This inevitably
| pushes people who use those tools towards using their local OS
| as a glorified terminal window manager for dialing in to Linux
| VMs because nothing works right if they try to use Windows or
| macOS directly.
|
| If your app genuinely needs something only AWS can provide then
| yes, you have to develop in the cloud and not against a local
| implementation. But that's a bug not a feature, and if you're
| in that boat then you're exposed to all sorts of problems
| beyond needing to develop against production (e.g. opacity of
| failures, unexpected cost explosions). If you can run the bulk
| of your app on a JVM with a Postgres connection then that's a
| competitive advantage - your devs can use the environments
| they're most comfortable with, you've got full insight into the
| whole stack if anything goes wrong, outages can't shut down the
| whole development team and you're not racking up cloud charges
| for development purposes.
| bhewes wrote:
| Haha, people who never have worked with an IBM mainframe think
| all this is new. Shallow IT thinking.
| ur-whale wrote:
| > General purpose computation on your own machine is probably
| going to be illegal in 20 years...
|
| This - to me - is the worst part of the article, because as much
| as I loathe the idea, I fear this may be correct.
|
| I am very afraid that, at the very least, you'll likely need some
| sort of carry permit to be allowed to write code on a machine
| connected to the net and where everything the machine does is
| connected to that permit and your identity.
| longrod wrote:
| > Fast gigabit internet is cheap and everywhere (5G or mesh wifi)
|
| Right. Most of the world doesn't even have 5G yet. Besides no
| matter how fast you get with internet, its still internet. There
| is still latency which makes for a frustrating UX.
|
| I wouldn't want to be fully cloud based even if I had free
| internet for life. That's a recipe for disaster. The best thing
| about local stuff is...that it's local. I don't need an internet
| to access it. That's extremely convenient.
|
| But putting that aside there's still cost of running things live
| (outside the internet cost). And why would I want to pay extra
| for something I can easily run on my machine locally? Live is for
| production code that multiple people will access. Local is good
| enough for me.
|
| I would even prefer to self host most of the stuff locally on a
| Raspberry Pi or something instead of a cloud hosting. It's just
| so reliable.
| cols wrote:
| I very much agree with this and did exactly the same thing not
| too long ago. I have a few small apps running on my Raspberry
| Pi. I converted it to run from a flash drive and it has been
| very, very solid for about a year now.
| sigmonsays wrote:
| to further this along, often i code without internet and just
| have VMs on my laptop. I think assuming internet is everywhere
| for development is wrong.
| Lev1a wrote:
| I'd go so far as to say that "Internet will always be
| available" is the new generation of "Works on my dev machine,
| thus it should work everywhere", which was a (common?)
| assumption over the last few decades.
| satyrnein wrote:
| Aren't people moving to cloud dev environments to _solve_
| the issue of "it works on my machine (using emulators,
| etc)"?
| LAC-Tech wrote:
| I've spent the last couple of years working in domains where
| users have very limited connectivity. In-fact I lived in one
| myself[0].
|
| It can be a bit of a mind shift for urban people to internalise
| that the internet is not always there.
|
| [0] https://lewiscampbell.tech/blog/220205.html
| rurp wrote:
| It's extremily frustrating how little thought many dev teams
| give to the idea that users won't always have super fast
| internet available. It really undercuts the grandiose
| corporate talk about inclusion and equity when users in rural
| and poor areas are effectively told to pound sand.
|
| One example that gets me is that Google Maps broke the
| ability to save points on the map without internet. It had
| worked fine for years since it could easily be saved locally,
| but now the regression has been around for a year+ and they
| clearly don't care. If you live your life in a modern city
| it's no biggie, but it cripples some of the main
| functionality for everyone who lives or travels to areas with
| poor connectivity.
| lucumo wrote:
| > It's extremily frustrating how little thought many dev
| teams give to the idea that users won't always have super
| fast internet available.
|
| We need to fix those places. Not permanently anchor the
| rest of the world to a decade ago.
| pcthrowaway wrote:
| I think the move to WFH has accelerated this shift (a
| worthwhile tradeoff IMO)
|
| Previously when working with a company (small startup or large
| company) you'd have an office LAN and a few servers, or a
| corporate VPN which your office network was on, and Openstack,
| or other 'local' services available.
|
| Now that a large number (the majority?) of devs are working
| remote, if you want local/internal services you need to get
| everyone's buggy VPN software configured correctly
| josephcsible wrote:
| If cloud services don't need a VPN to use, why would
| companies' self-hosted services?
| simonw wrote:
| The bullet point you quoted there sits directly under this
| heading:
|
| > Make the ultimate developer experience wishlist for the
| average rich-country developer in 2030
| jasonlotito wrote:
| Not the OP, but I'm fairly certain that is the point: Fast
| gigabit internet cheap and everywhere won't happen by 2030.
| 5G isn't even everywhere yet, so making it fast and cheap
| everywhere happening by 2030 is highly unlikely.
| cgrealy wrote:
| Hence the term "wishlist".
| hemloc_io wrote:
| recently I've had a week long internet outage, and it's really
| put in perspective how much I'd like things to be local.
|
| You don't need it until you do.
| Nextgrid wrote:
| It is extremely difficult to actually get good internet on
| short notice, at least in the UK.
|
| Mobile, while technically capable of this, does not fit the
| bill because their business model depends on locking people
| into long-term contracts or using it as a marketing platform
| (I've tried launching a startup that does away with all this,
| it's impossible).
|
| Right now nobody will sell you a SIM with unlimited data
| (excluding Three because their "unlimited data" is so
| oversubscribed that it's unusable) or a large enough data cap
| no matter how much you are willing to pay. Your only option
| is to either sign up for a yearly contract (which involves
| wasting time with support if you ever need to make a change
| or need to increase your data cap) or use Pay & Go SIMs and
| top them up regularly which involves using an IVR and
| listening to minutes of upselling random bullshit - there's
| no API and the billing is intentionally complex (depositing
| money isn't enough - you have to use that balance to buy a
| "bundle" of data, and you can't stack these bundles meaning
| you need to do this every time it runs out).
| ectopod wrote:
| BT sell broadband with a mobile fallback if the broadband
| fails. I'm pretty sure one of the other ISPs offers it too.
| I've never tried it though.
| secondcoming wrote:
| Vodafone sell unlimited data 5G SIMs, but with a contract.
| I replaced fibre with one.
|
| You seem to be looking for a no-contract unlimited data
| plan? Isn't that just PAYG?
| Nextgrid wrote:
| > You seem to be looking for a no-contract unlimited data
| plan? Isn't that just PAYG?
|
| Kind of - I did mention PAYG and why it's not ideal and
| that it feels like you're still fighting the provider.
| Topping it up is a nightmare and the billing system
| doesn't allow the scenario of "here's a few hundred
| bucks, give me internet consistently until this runs
| out". Instead, you have to fight with it every time your
| "bundle" expires and you can't stack them in advance even
| if you deposit enough cash on the account.
|
| EE's biggest bundle on PAYG is 100GB for 30PS which is
| reasonable from a pricing point of view but unfortunately
| doesn't last long and forces you to top-up and reset the
| bundle via the IVR every time it runs out. I want to be
| able to put 300PS on the account and get 1TB of data in
| one go so it lasts a couple weeks before I need to top-up
| again (topping up relies on the IVR which means taking
| the SIM out of the 4G router and putting it in a phone
| then sitting though minutes of bullshit upselling).
| prmoustache wrote:
| Sounds like almost a week of additionnal days off from both cloud
| vendor and local power outages. :)
| marginalia_nu wrote:
| Ugh, I know right. You're tired of owning your house :-(
|
| That's what people did in the past. Eww. Leave the past behind!
| The past is bad!
|
| Instead, live in the cloud!
|
| Sign this easy form and transfer the property rights to me, and
| for a monthly bill, you will be entitled to visit the building.
| Need to use more than one room, need to turn on the lights or use
| the stove? No worry, you will be billed separately for abnormal
| usage.
| jacquesm wrote:
| That's really pretty dumb. I run plenty of stuff on my local
| machine that has nothing to do with development, it simply runs
| there _because I only want it to run on my local machine_. So
| localhost _is_ my production environment.
|
| The idea that some bozo somewhere will decide what I can do with
| my local machine just because they don't have a usecase for it is
| really meddlesome. Go and disable localhost on your own box.
| Leave mine alone.
|
| And that goes for the endless number of usecases that haven't
| been tallied yet.
| spc476 wrote:
| You haven't been assigned a corporate managed laptop yet, have
| you? You don't have administrative rights, and it doesn't come
| with any development tools (because that's _dangerous_ ), but
| it does come pre-installed with all the Microsoft Office Tools
| that spend all the their time looking for updates.
| borland wrote:
| This is a terrible idea. Understanding what's "underneath you" in
| the stack is a critical ability when things get complicated. In
| my experience, running the stack on your local machine as a
| developer gives you a huge boost in understanding the stack,
| being able to profile, inspect, and reconfigure it as needed.
|
| Sure, it's quick, convenient and easy if your dev stack is also
| the cloud stack, because you save time not trying to figure out
| why localhost mismatches the cloud. BUT, when things get messy,
| having that understanding of HOW EXACTLY your localhost
| mismatches the cloud gives you a great depth of knowledge, which
| you can then use for great benefit in the cloud.
|
| Also: remote debug tooling is crap.
| joshstrange wrote:
| One good work around for this that I've found (it's not perfect
| but it gets the job done) are Cloudflare tunnels. You could also
| use something like ngrok but you can use CF Tunnels for free.
|
| I just setup projectname.mydomain.com or
| projectname.local.mydomain.com and I have that use a CF tunnel to
| my local dev environment.
| barnabee wrote:
| Let's not do this. It is a gross vision for the future. I hate
| the cloud.
|
| IMO we should be working towards self hosting appliances,
| federated and otherwise decentralised services, and local-first
| applications.
| amelius wrote:
| The future looks cloudy.
| dzonga wrote:
| you see people / companies advocating for the cloud thing have
| huge interests in you/me - joe average developer to using cloud
| tools. BigCo's development workflow is cloud based because they
| own the IP.
|
| IP - being the most important word. looking at world around me,
| IP is what makes things tick. IP is why America industrialized,
| IP is why American's are spooked by the Chinese.
|
| And if a average joe like me - moves to the cloud things - where
| i'm using a dumb terminal n hell the browser is being streamed to
| me. What IP would I own. I would simply be a renter.
|
| now me your average developer since realizing IP is the most
| important thing - I have resolved to go the opposite route. use
| text files for my notes / writings. create things locally and
| back them locally as well. SSD's and CD's are cheap. Desktop
| machines are cheap - an Alder Lake i5 is as fast. and even better
| maybe instead of making software for the browser making local
| software with C++ to make sure it's portable and runs fast who's
| data is stored in a text file.
| jacquesm wrote:
| That, and cloud usage means they control you, the tools you
| use, when you can use them, from where you can use them and
| that's before we get into telemetry and so on.
| whoomp12342 wrote:
| you know what I love about working against localhost?
|
| its LOCAL. its mine. I know its mine and no one can see it until
| I push my code. I have ideas. Good ideas, bad ideas, and WHAT THE
| FLIPPING HELL WAS ThAT idea. In the wrong hands any of those half
| baked ideas can not be good
___________________________________________________________________
(page generated 2022-06-08 23:01 UTC)