Delphi and Visual Basic 6 were definitely not the pinnacle of UI development.
For example, all layout was pixel based. Making windows resizable required much complex ad-hoc code, and internationalization was hard as well. Very early in my career, I have spent person months clicking through every single screen in a large desktop application to find words cut off due to words having different lengths (measured in pixel) in different languages. I knew what "Ok" and "Cancel" meant in half a dozen languages. At the time, Java was really breaking ground with container based layouts in Swing. Delphi and Visual Basic caught up only in the .NET era.
Don't know about VB6, but at least Delphi had Align property and TPanel/TGroupBox. Together, it allowed to make apps that handle resizing just fine without any custom logic.
(it has been a very long time, but I think those only handled internal composition and not overall window size.. so you'd still need some custom code if you wanted dialogs as compact as possible. But as long as you never missed setting Align property, you did _not_ have to manually resize every control for different text/font size).
It's actually not entirely correct with respect to VB6. It did indeed use absolute layouts, but unlike Delphi with its pixel units, in VB everything was measured in "twips" (1⁄1440 of inch, or 1⁄20 of point). This would then be converted to actual pixels based on the DPI setting of the system.
> Delphi and Visual Basic 6 were definitely not the pinnacle of UI development.
> All layout was pixel based.
I'd say that was a very reasonable trade-off at the time, when most screens were somewhere between 640x480 and 1024x768 resolutions at 72 DPI. This simplified UI design sufficiently enough that VB/Delphi provided an optimal solution that, yes in hindsight, would most accurately be described as a "local maxima" for the environment and the time.
> Making windows resizable required much complex ad-hoc code
I remember there were ActiveX controls one could drop onto their form that would attempt to derive the layout based on initial positioning of controls, i.e. that a lower row of buttons should be anchored to the bottom of the window, while textboxes are took up a larger area would automagically resize with the window.
These sort of excuses always come up when Delphi and its insane productivity is mentioned. The same thing happens in conversations about how slow software has gotten.
High-DPI displays, internationalization, and accessibility are a pain but don't introduce enough complexity to hand-waive away the criticism.
Going a bit off-topic, but the browser is carrying around so many legacy concepts and ideas - it's a complete disaster - but it's the only option. The document object model is slow and weird to use to build reactive user interfaces.
We should demand something better. The browser is a local maximum as an application platform, and we should stop defending it.
You can’t look at the language in isolation. Visual Basic was backed by the fantastic Visual Studio for development. That ecosystem was way more mature than Java ever got with Swing et al. IMO, if there’s one thing MS ever did right, it was how they nailed WYSIWYG GUI app development. Now they’re going backwards with the WinUI XAML crap.
The experience has become worse with WinUI 3. They got rid of the designer view. So now you're developing the UX code first. This is very unlike the prior paradigm, where you would typically drag and drop the components in your workspace/design view and then code the interactions. It is precisely what made Windows programming so accessible to the millions of developers. This is a step in the wrong direction IMO.
I came from Visual C++/Basic world when I first got my Mac and dove into Xcode for the first time (2002? 2003?). Flexible layouts, connecting UI elements to datasources, localization...
VB6 (and its predecessors) didn't ship with windows resizing and alignment out of the box, but there were 3rd party components that did that nicely. This happened way before Java.
Yes it did, IDE tooling was the answer, and Netbeans still provides its Matisse, WindowBuilder on Eclipse, and as does InteliJ.
Back in the day, JBuilder offered a Delphi like experience.
What I would agree is that the thing that actually made Swing hard are the defaults, which required books like "Filthy Rich Clients" as gate into making wow Swing applications.
Olympic weight plates for barbells. They're widely used, so competition has brought the cost down, and they're easily available in useful increments. I currently see 4x 10lbs for <$50 on Amazon. That works out to 2,53 Euro per kg. So cheaper than euro cents. They may not have the exact shape you need.
The scrap steel probably didn't cost cents per kg when it was sold for its original purpose. You are paying for a useful shape.
A professional equivalent of weighted vests are ballistic plate carriers. Real ballistic plates can be fragile and expensive, so options for exercising in (or milsim games in airsoft etc.) include expired (and failed to re-certify) real ballistic plates, made for purpose training plates... or plate shaped sandbags!
For general public restrooms, you can also search OpenStreetMap for amenity=toilet and access=yes (which means explicitly open to the public; see also access=customers). Try it: https://overpass-turbo.eu/s/1ORn
The main technical limitation is that /24 is the smallest prefix that is widely accepted. So you can't just announce a /32 (single IPv4) at different locations.
Generally speaking, if you own the IP space, it just needs to be announced in BGP and traffic will come. You can either peer with someone yourself and get transit from them, or have them advertise it for you.
It's possible even for a private person to do it, if they have one of several workable mixes of knowledge, time, cash, contacts and technical requirements. I've done it for a while.
The main practical question really is who will peer with you and with what conditions. For example, your ISP will absolutely not do this on a consumer plan, but might on a business plan. AWS will do it for busineses as well: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoi...
If you want to learn more about BGP, anyone can sign up for DN42, which is a free, large, shared environment that is a small scale replica of the internet. Everyone gets to be their own AS, get some IP space allocated, establish links to other participants (usually VPN tunnels over the real internet), and do BGP peerings over them. https://dn42.eu/Home
It's written in an ambiguous way and you interpreted it incorrectly. "G5 Conditions were first observed at Earth at 6:54 p.m. EDT today." should be read like "today, G5 conditions where first observed at 6:54", not "G5 conditions where first observed today (at 6:54)".
Those are all arguments for buying Tesla stock, not a Tesla. Of course Tesla will keep selling new cars.
What if Tesla pulls the rug on existing models and stops supporting them after a few years? It's not an outlandish fear. Musk has been wildly unpredictable, anything could happen. And given e.g. the recent story about how a Tesla car wouldn't even start again without calling support for some kind of remote maintenance, Tesla owners seem to be more dependent on the company's support than average. It wouldn't surprise me at all if Teslas were generally one expired TLS certificate inside the car away from being bricked.
Unraid is not confidence inspiring either. It's just more commercial closed source software, developed behind closed doors and with a slow update cadence (~3 months). They have made questionable security choices anywhere you can see, and I have strong doubts that their code quality is any better.
The PHP scripts certainly are a horrible mess, in all ways. For example, shell injection prevention is based on using escapeshellarg at each call site... that pattern is _exactly_ the structural root cause for vulnerabilities like the one D-Link had.
In no particular order, and obviously not exhaustive: Everything runs directly as root - nginx, php-fpm, smb, ... No AppArmor/SELinux. There is no Secure Boot support (especially unfortunate since boot is from USB stick). No HTTPS access to web frontend by default. SMB protocol defaults are insecure. SMB shares default to public. SSH allows password-based root login. Pools are unencrypted at rest by default. They have a checkbox to enable telnet for management! Very permissive iptables rules. Almost any features that real competitors like Synology would officially provide come from third parties via a moderately shady app store.
Note it's not about any of these individual points. I see above as signal that they are not security experts and see security as an afterthought, rather than as something that deserves a team of experts that specifically cares about it.
(There's certainly other fields they also aren't experts in, like UX - their predominant UI pattern is "list of dropdown fields". Even in storage, one could have a longer discussion how their Array feature - the true core of their product -, compares to modern solutions. There's a reason they've evolved cache pools to just pools as a separate thing, and some users do pool-only Unraid...)
That's all quite understandable since it's a small team with only 2-3 coders (https://unraid.net/about). But nevertheless.
> Everything runs directly as root - nginx, php-fpm, smb,
For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that.
Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day
You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy.
There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does).
You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances.
None of this is new; this was already widely considered best practice when I was starting out 25 years ago.
in its service file. Note that this will necessarily allow the process to listen to any port; there is, unfortunately, currently no way to lock it down to a single port.
You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.
Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation).
(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)
I was specifically referring to hereditary peerage in the House of Lords, which was almost completely done away with. At around 13% of members, the chamber is largely no longer a chamber of hereditary peers. Hereditary peerage and hereditary peerage participation in the house of lords are separate. There are around 800 hereditary peers, but since 1999, only 92 of these hereditary titles have a spot in the house of lords. The hereditary peerage granted to Prince Edward is not one of the 92 hereditary peerages in the House of Lords, so it doesn't allow him participation.
The obvious difference is that the throttle axis on RC transmitters is not self-centering. 0% is at the bottom, not in the center.
But beyond that, the stick throws are much larger than e.g. on an Xbox controller, there's much finer feeling, the end stops are harder, the sticks can be held differently (search "thumbing vs pinching", both are used irl but the latter gives finer control). It's just so different. And you can't compare at all to using two full sized joysticks, which would mean full wrist movement.
Also, cheap gaming joysticks are terrible. Two high quality ones (VKB NXT or better) cost more than a high quality RC transmitter. It does not save money.
Physics aren't really realistic. They're all enough to get the absolute basics down (e.g. that camera uptilt means that pitch left/right needs a corresponding yaw input to keep the view straight). But then different simulators vary. The most common, fairly ubiquitous complaint, is that it's too floaty (real quads drop much faster without throttle). It's not just due to bad physics, it's also because to be commercially successful they have to appeal to gamers too, maybe even primarily. Then there's the finer points, like wind, descending into your own chaotic vortex, or how easy you crash when you touch anything (sims are sooo forgiving).
And of course every quad is different, 1" 1S, 3.5" 2S Li-Ion and a 10" 4S handle substantially differently, but if you haven't flown any for real then you won't know what is right.
(If you're looking for a radio, unless you know what you want, just buy a TX16S please.)
(There are exceptions to everything I said above. But this is the common case.)
I mean, I figured every different size drone would handle differently.
I guess I am surprised there isn't or can't be a quadcopter simulator with really realistic physics though in this day and age. Maybe just not enough market for it for that level of accuracy and realism.
To be clear, I don't want to imply they're useless though. Velocidrone, DRL and Liftoff (I haven't tried Uncrashed yet) all have good enough physics for real use cases, and are widely used.
- As a beginner, they help you crash less. You can learn enough basics to save some real money in avoided crashes. The sims pay for themselves right away, you can just buy them all. The sim-isms don't matter so much.
- As a skilled pilot, they help you crash more. You can safely iterate on your maneuvers really really well (no repairs, immediate retry from same conditions, always good weather, fly from home). You'll have an idea where the differences are and how you need to compensate with the actual craft. You can tune the virtual counterpart to be a bit closer.
They complement real model flying, they just cant replace it. (And even that is questionable. I bet many just can't afford real model flying. Sims might help them scratch the itch.)
A _really accurate_ flight sim is actually hard to do though, for a few reasons. Aerodynamic modelling is hard (there are lots of interesting effects), and that almost every model aircraft is unique (due to home building) and constantly changes (crashes, repairs, upgrades) probably doesn't help. And neither does that the core idea behind multirotors is unstable flight, which entirely depends on the firmware. There are different firmware projects (Betaflight is the most popular for racing, but not the only), and they are quite tunable. Can't simulate that accurately; it would have to be firmware in the loop.
For example, all layout was pixel based. Making windows resizable required much complex ad-hoc code, and internationalization was hard as well. Very early in my career, I have spent person months clicking through every single screen in a large desktop application to find words cut off due to words having different lengths (measured in pixel) in different languages. I knew what "Ok" and "Cancel" meant in half a dozen languages. At the time, Java was really breaking ground with container based layouts in Swing. Delphi and Visual Basic caught up only in the .NET era.