As someone who had to develop software in an airgapped enviroment, I'm sending a special "fuck you" to whoever thought this is a good idea. God forbid you have the AUDACITY to not be connected to the internet at all times for any reason whatsoever.
Syncing / uploading then happens once they have signal again. Or in the case of the Garmin I copy the FIT file off by hand when plugging it into my computer.
There are many apps that let you track your run/hike/ride without internet connection.
Personally, I think a dedicated bike computer is best, because then the phone's battery is saved for emergency uses instead of recording a ride. For long rides (8-10 hour) phones won't have enough battery to record the whole ride.
An android app is software.
Not hardware.
No log in, no external services.
Even if it cost money to install, you are just paying for the privilege of being tracked by those folks instead of others.
#appsnotevenonce
- Sygic,
- Topo Map+,
- 2GIS
- Starwalk - Night Sky 2
- and my fav, Genius Map
all works without WiFi, cell coverage, nor NFC/bluetooth
Hardware is cheap, network is reliable. Move fast and break things.
Neither of these assumptions are true, and we're going to have these issues by truckload, until we understand and change our mindset.
At least the website works, even though it transmits the full site for every request...
Scuba diving spots on the world are rarely well covered with internet and even if they are, still many people don't have the roaming/local SIM solution for it.
Guess where you want to use that damn app the most?
Discovered this when I tried to add a WiFi password before connecting to it.
Not a great way to get new customers though as it requires missing out on logging a ride to become aware of a reason to buy.
https://www.verizon.com/about/news/how-far-does-5g-reach
> 5G Ultra Wideband network’s signal can reach up to 1,500 feet without obstructions
> 5G can be implemented in low-band, mid-band or high-band millimeter-wave 24 GHz up to 54 GHz. Low-band 5G uses a similar frequency range to 4G cellphones, 600–900 MHz, giving download speeds a little higher than 4G: 30–250 megabits per second (Mbit/s). Low-band cell towers have a range and coverage area similar to 4G towers.
— https://en.wikipedia.org/wiki/5G#Overview
5G is _perfect_ for providing coverage in rural areas, except for the problem that 4G devices are incompatible with 5G networks. Starting 5G rollout in urban areas makes more sense because (a) 5G provides most benefit when clients are close together, and (b) because denser cells make it reasonably economical to maintain 4G coverage in parallel to 5G coverage.
Either way, if we're talking about "coverage" for low-bandwidth stuff like fitness trackers, it's the spectrum that matters more than anything. We can communicate thousands of miles on 1 or 2 watts of LF spectrum using technology that is nearly a century old. Don't need 5G for that, just need to use the right spectrum.
I certainly wouldn't want to ask that the other 99% of the world's developers avoid a feature that's useful to them just to assuage my feelings of envy about the convenience they enjoy.
Nope. The exe files are supposed to do it's thing without internet and no extra effort like it was for a long time.
This does mean that certain programs just won't work, or won't work without some finagling. That's also a feature. The price of control is having to control things.
Granted, most people don't want to pay that price, and prefer convenience. That's admittedly not to my own taste - c.f.) log4j for a good example of why - but I think I'm maybe a little weird there. I certainly don't think there's anything audacious about catering to majority tastes. Maybe just vaguely disappointing.
Saying people prefer one to another hides the fact that they were not given any other option. People will choose whatever default is given and then we may say they everyone prefers that. Or just make the other option (which was normal before) complicated so that nobody wants that now.
Contrast this with e.g. Zig for Windows is a ~60 MB zip file which contains the entire Zig/C/C++ compiler with cross-compilation support for basically everything, and also has complete Win32 headers + libraries in it. There's even DDK headers in there, though I'd expect to do some legwork to build drivers for NT with Zig.
I'm not really sure what you're complaining about here. .net core is split into tiny packages - if that is hard to handle in your very special environment, you get to use special solutions to make it work.
That being said, WinForms is also "just" a Win32 wrapper, I don't see a compelling reason why a similar wrapper wouldn't be possible in pretty much any language. .NET 4.6 is a fine choice too, especially because you're not forced to ship runtime and standard library, as Windows already has both.
We don't even require the internet for building/development. In .net land you require internet to get the dependency you're using the first time. If you want to get them all and distribute/install before you start development, you can totally do that. It's just not the default behaviour.
I get that you have opinions, but you seem to have entirely missed that the runtime is downloaded at build time and included in the bundle. And god forbid if you like doing everything by hand, you don't have to use Nuget and you can manage every last dep by hand, however you like (and you'll likely end up hacking something that is less usable than just setting up a private nuget server, but "opinions").
Yes, technically easy but if their work environment is strict enough to enforce air gapped development, I imagine the bureaucratic process to accomplish such a thing to be a bit less than easy.
Do you even know what an airgapped computer is?
I wouldn't say the campfire was ruined, by my goodwill toward this product certainly was.
Your goodwill deterioration does not matter unless you switch a new a app[1], and a) Make sure that new app can function without internet, and b) Tell your current app developers why you are switching.
So, yeah, your goodwill is irrelevant is you're still giving them money or value. [1] I assume that it's a subscription - most things are nowadays.
Usually you had to dig a bit and could find an "offline installer". Sometimes an "alternate downloads" link is on the initial download page, sometimes you have to good to find a deeper link on the vendor's site.
I always did that just to keep from needlessly reaching out to the internet X times when updating X machines.
And of course, make sure you're getting it from the vendor and not some sketchy download site.
What if I installed the software with the intention to run it without internet, or 5, 10 or 100 years in the future?
You can download all versions of Android if you want, but i doubt that you would want that.
And yes, this sucks. But if you want freedom, there are other OSes (or even other dev tools) where you can have it.
This is important because I support each release of the distribution for up to 10 years, and have some customers who may need to build it in an air-gapped environment.
[0] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...
Personally, I just run things in network namespaces with "ip netns exec offline|wireguard $COMMAND" to restrict net access.
I thought about using a network namespace, but that would make things more complicated since I would need to re-call my shell script to pick-up where I left off (because it requires creating a new process). I initially tried to implement this using network namespaces, but you cannot "unshare" the current process, you must spawn a new process.
With dropnet I can do
download()
enable -f ./dropnet.so dropnet
configure()
build()
install()
In this particular scenario, my first thought was "shoulda used golang".
I hear tell that since then (1+ yrs ago) matters have improved in the realm of MS standalone apps (well, maybe just cmd line apps).
oh, and the exe is round about 65mb compared to a golang ~5 or 6mb
You can even prefetch popular libraries: https://crates.io/crates/cargo-prefetch
And you can likely mention it as an explicit dependency in your csproj so that you can download it on first restore.
Also, when you write something on those environments, you know users cannot install a runtime. So you get in touch with IT teams to ensure which version of runtime they are deploying. If and only if you have to update it for proper reasons, then they can deploy newer versions to the clients. For all or for a specific user base. This is how it works.
Without an actual business case or a security concern, you don't just go from a runtime to another, let's say 4.8 to 6.0. So yes, development in airgapped environments is PITA. But it's the same with Java, Python, Perl, etc. That's not the fault of the runtime but the development environment itself.
That's exactly what you have to do here.
I understand OC issues with the difficulties associated with using M$ tools with limited internet but wonder if the "Air Gapped" example may be a bit extreme.
Being required to work from home while still meeting an employers' secure network policies might be more common.
The end result is a Golang-like, single binary experience that runs on many platforms easily and rapidly.
Though I can master a lot of programming languages, I miss C# the most especially on async/await and LINQ. Rust is what I'm favourited in second places with a lot of similarities of C#.
[1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
But to this day, nobody knows what data your system telemetries to Microsoft. Not the data they talk about in the 5-10 page license. Instead, the data mentioned in the 55 page doc about what you agree to send them, that they refer to from the MS Software License...
Like every other dev system, connect, either download offline installers for everything (they exist), or get your system running, then you can dev offline all you like.
You don't need to "be connected to the internet at all times for any reason whatsoever". You need it once.
What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.
If you don't want it to download anything then you use the `dotnet publish --no-restore` flag, which is used a lot in CI/CD pipelines. If you don't have the package dependencies cached it will then simply fail.
The internet exists, the industry has evolved, software has dependencies, and yes you have to download them (just like you had to download the SDK ISOs back in the day). But it's just one command, run it and get it over with, and after that up-front one-time pain you'll have a nice offline workflow.
I should be able to take my computer to a remote cabin with no Internet, and use all the software on it. The only software I'd expect to not work is software whose purpose is to access data stored on the Internet, like web browsers. I don't think this is such a crazy user expectation.
For many, it is not so black and white. Internet connections are spotty, slow, or expensive. In GP’s case, there is no internet.
Like I said, you are welcome to ignore those users. But your ignorance (I don’t mean that in a derogatory way) doesn’t change their situation.
That is easily doable. However users often don't want a copy of a large runtime for each and every program they use, so it often makes sense to move common things (like DLLs, runtimes, your OS) to libraries that can be shared.
You can easily make dotnet apps in either flavor to your liking. And not every developer is going to make their apps to appeal the your needs.
In days gone by we used to have truly standard libraries and runtimes, in the sense that they came with your build tools out of the box and so were available everywhere. Host platforms similarly provided basic services universally. Documentation was often excellent and also available out of the box.
In that environment, writing "Hello, world!" meant writing one line that said do that, maybe with a little boilerplate around it depending on your language. Running a single simple command from a shell then either interpreted your program immediately or compiled it to a single self-contained executable file that you could run immediately. Introducing external dependencies was something you did carefully and rarely (by today's standards) when you had a specific need and the external resource was the best way to meet that need.
Some things about software development were better in those days. Having limited functionality in standard libraries and then relying on package managers and build tools where the norm is transitively installing numerous dependencies just to implement basic and widely useful functionality is not an improvement. The need for frameworks and scaffolding tools because otherwise you can spend several hours just writing the boilerplate and setting up your infrastructure is not an improvement.