Software disenchantment
-
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
Embedded programming is badly suited to agile programming, everything is planned in advance, "ship now, fix later" is usually a no-no in the kind of embedded programming I'm thinking of, and there is little or no feature creep because you have very rigid constraints.
Literally everything you said in this sentence is wrong. It's kind of amazing, but also expected from someone who have zero knowledge of what they're talking about.
You are trying to tell me that in industrial embedded applications (you know, the ones where a bug can cost millions) you use agile programming, there is no planning, you adopt a very cavalier approach to testing and you add countless badly thought out features just because you can?
Hey, did you know that there's a whole spectrum of possibilities between the two extremes? Yes, embedded is much stronger about quality than webdev. But it's still a long cry from what you've described earlier. Planned 0-day patches are totally a thing, especially when software is put on re-writable memory (it usually is). Agile is used even if it doesn't make sense because everything is pre-planned. And despite the pre-planning, the plan changes constantly along the way as more design bugs are discovered. And feature creep is just as real as everywhere else - it just happens earlier in the pipeline, and has to account for hardware capabilities so there's a bit less of it. But it's still a thing.
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
Embedded programming is badly suited to agile programming, everything is planned in advance, "ship now, fix later" is usually a no-no in the kind of embedded programming I'm thinking of, and there is little or no feature creep because you have very rigid constraints.
Literally everything you said in this sentence is wrong. It's kind of amazing, but also expected from someone who have zero knowledge of what they're talking about.
You are trying to tell me that in industrial embedded applications (you know, the ones where a bug can cost millions) you use agile programming, there is no planning, you adopt a very cavalier approach to testing and you add countless badly thought out features just because you can?
Hey, did you know that there's a whole spectrum of possibilities between the two extremes? Yes, embedded is much stronger about quality than webdev. But it's still a long cry from what you've described earlier. Planned 0-day patches are totally a thing, especially when software is put on re-writable memory (it usually is). Agile is used even if it doesn't make sense because everything is pre-planned. And despite the pre-planning, the plan changes constantly along the way as more design bugs are discovered. And feature creep is just as real as everywhere else - it just happens earlier in the pipeline, and has to account for hardware capabilities so there's a bit less of it. But it's still a thing.
The simple fact that there is more emphasis on quality is enough for me though.
-
@Applied-Mediocrity said in Software disenchantment:
And something that doesn't seem like saving any bytes - counter value 0..10 that toggles 11 bits instead of counting normally
It's saving gates, not bytes.
Which reminds me…
WHATEVER YOU DO, DON'T LET HARDWARE ENGINEERS WRITE SOFTWARE!
Seriously, just don't.
-
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
Embedded programming is badly suited to agile programming, everything is planned in advance, "ship now, fix later" is usually a no-no in the kind of embedded programming I'm thinking of, and there is little or no feature creep because you have very rigid constraints.
Literally everything you said in this sentence is wrong. It's kind of amazing, but also expected from someone who have zero knowledge of what they're talking about.
You are trying to tell me that in industrial embedded applications (you know, the ones where a bug can cost millions) you use agile programming, there is no planning, you adopt a very cavalier approach to testing and you add countless badly thought out features just because you can?
Hey, did you know that there's a whole spectrum of possibilities between the two extremes? Yes, embedded is much stronger about quality than webdev. But it's still a long cry from what you've described earlier. Planned 0-day patches are totally a thing, especially when software is put on re-writable memory (it usually is). Agile is used even if it doesn't make sense because everything is pre-planned. And despite the pre-planning, the plan changes constantly along the way as more design bugs are discovered. And feature creep is just as real as everywhere else - it just happens earlier in the pipeline, and has to account for hardware capabilities so there's a bit less of it. But it's still a thing.
The simple fact that there is more emphasis on quality is enough for me though.
At the cost of abysmal dev tools?
Edit: also note that "more emphasis on quality" doesn't imply "emphasis on qualiy". They're still horrible at it, just less so.
-
@Gąska said in Software disenchantment:
Are compilers generating invalid assembly tolerable to you? Are bugs in standard libraries resulting in totally different behavior than the standard says, tolerable to you? Because it's bread and butter of embedded folks.
Keeps you on your toes. Shouldn't trust the compiler.
-
@Gąska said in Software disenchantment:
Are compilers generating invalid assembly tolerable to you? Are bugs in standard libraries resulting in totally different behavior than the standard says, tolerable to you? Because it's bread and butter of embedded folks.
The compilers usually generate valid assembly. It just usually also miserably inefficient. The problem is that compilers have cost models for operations that are tuned for desktop and server systems, but embedded CPUs have different cost profiles; inter-register moves and immediate loads are relatively more expensive, and loads from memory can be comparatively surprisingly cheap (if the memory is colocated in the same package). And that's before we start considering the weird partitioned memory structures that often exist.
Another problem is that gcc apparently can't interleave memory accesses on ARM worth a damn. I've no idea why — the problem is probably somewhere in the GIMPLE layer which scares the bejeezus out of me! — but it totally hobbles the code it issues. ARM's commercial compiler does a hell of a lot better job here, but that's a PITA to use for other reasons; getting a CI service working with FlexLM isn't something I want to try… I'd love to use clang, but we're using a language extension unsupported by it (or by MSVC, but that doesn't generate code for our target architecture at all which kind of knocks it out of this race at the first hurdle).
-
@dkf said in Software disenchantment:
Which reminds me…
WHATEVER YOU DO, DON'T LET HARDWARE ENGINEERS WRITE SOFTWARE!
Seriously, just don't.Hey!
-
@HardwareGeek said in Software disenchantment:
@dkf said in Software disenchantment:
Which reminds me…
WHATEVER YOU DO, DON'T LET HARDWARE ENGINEERS WRITE SOFTWARE!
Seriously, just don't.Hey!
I'm sorry about the broad brush, but I've seen things, man, I've seen things… :thousand_yard_stare:
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
Embedded programming is badly suited to agile programming, everything is planned in advance, "ship now, fix later" is usually a no-no in the kind of embedded programming I'm thinking of, and there is little or no feature creep because you have very rigid constraints.
Literally everything you said in this sentence is wrong. It's kind of amazing, but also expected from someone who have zero knowledge of what they're talking about.
You are trying to tell me that in industrial embedded applications (you know, the ones where a bug can cost millions) you use agile programming, there is no planning, you adopt a very cavalier approach to testing and you add countless badly thought out features just because you can?
Hey, did you know that there's a whole spectrum of possibilities between the two extremes? Yes, embedded is much stronger about quality than webdev. But it's still a long cry from what you've described earlier. Planned 0-day patches are totally a thing, especially when software is put on re-writable memory (it usually is). Agile is used even if it doesn't make sense because everything is pre-planned. And despite the pre-planning, the plan changes constantly along the way as more design bugs are discovered. And feature creep is just as real as everywhere else - it just happens earlier in the pipeline, and has to account for hardware capabilities so there's a bit less of it. But it's still a thing.
The simple fact that there is more emphasis on quality is enough for me though.
At the cost of abysmal dev tools?
Edit: also note that "more emphasis on quality" doesn't imply "emphasis on qualiy". They're still horrible at it, just less so.
Eh, it's infuriating but that's one of those "that's life" situations. You get the bonus of complaining with your fellow co-workers about something everybody has to suffer from and there is nothing you can do about it.
-
@dkf said in Software disenchantment:
Which reminds me…
WHATEVER YOU DO, DON'T LET HARDWARE ENGINEERS WRITE SOFTWARE!
Seriously, just don't.
If you do that, you get
Samsung.You might even end up
Enlightened.
-
@admiral_p somehow I got nothing of this quality and care about resources that you and @dkf are talking about, but got horrible tools like the ARM's commercial compiler (without a debugger, because nobody could figure how to use them with these things we have here) and visual c++ 6 (the one MS released at 1998), and crap like that.
-
@sockpuppet7 said in Software disenchantment:
because nobody could figure how to use them with these things we have here
Nobody's got the JTAG interface working on your development board? Things are pretty miserable if you can only debug by flashing an LED…
(JTAG is how we program our truly development stuff, the bits that are still sitting on $20k or so of FPGA. I'm not working on those parts yet; they've outright inconsistencies in the datasheets still, such as flat contradictions about what piece of hardware is mapped where, and I just don't want to handle hardware that alpha quality… and I really hope that they don't keep raw JTAG as a primary programming mechanism as we go towards prod. I already done one horrified exclamation today against what software written by hardware engineers tends to be like, and I'd rather not repeat the experience.)
-
@dkf No, none of these things are our hardware, there is no development boards around. Some of these stuff have a decent debugger, some we have to resort to printf debugging. Some are embedded because it's cheap, others are embedded because the battery has to last for a long time, and others aren't embedded at all. All of them are horrible for different reasons.
-
@sockpuppet7 said in Software disenchantment:
Some are embedded because it's cheap,
And how many units do they expect to sell that they expect to offset the added development costs?
-
@PleegWat I think I said somewhere, developers are dirty cheap in bumfuckistan, and electronics are expensive. We have a 6 digit number of wtfdevices out there.
-
-
-
@thegoryone said in Software disenchantment:
Bloated, without a doubt, but still bigger, and comes with drivers for 95% of peripherals out of the box which is something 95 didn't do.
I really wish there was a "net install" version that had only the absolute core components, all the NIC drivers, and everything else could be wizarded in from the 'Net when needed. Don't need printer drivers? Not stealing space by default! Don't use .Net? Totes fine. It would certainly reduce the number of SxS assemblies it keeps around, I believe, and if you also reduce any resources to the minimum and stream them down when used, we might be able to have a reasonable footprint again!
-
@Tsaukpaetra said in Software disenchantment:
Don't use .Net? Totes fine.
Yes you do. Nearly all the Win10 UIs are written in XAML.
-
@dkf said in Software disenchantment:
Want to send nastygrams to the owner? Sure. Badgering all the users as well? Fuck. Off.
No no, you misunderstand, the ploy is to get the users to badger the owner to pay $10/user/mo to upgrade!
-
@Tsaukpaetra said in Software disenchantment:
No no, you misunderstand, the ploy is to get the users to badger the owner to pay $10/user/mo to upgrade!
I'd rather badger them to switch to a platform other than Slack…
-
@M_Adams said in Software disenchantment:
@topspin said in Software disenchantment:
And it'll always be a kludgy 80% solution.
Which is perfectly fine if it helps the user to get something done right now, but it's the kind of stuff that ends up on the front-page when an entire organization's process starts to depend on some excel macro that the accountant hacked together 5 years ago.Now you’re just “Excel-shaming” me.
Every now and then I'm really sad I didn't get to keep my AutoDeck system. This week it's happened quite often...
-
-
@pie_flavor said in Software disenchantment:
@Tsaukpaetra said in Software disenchantment:
Don't use .Net? Totes fine.
Yes you do. Nearly all the Win10 UIs are written in XAML.
Is .Net 6 GB worth of data?
-
@Tsaukpaetra said in Software disenchantment:
So FLOPS are really SFLOPS?
FWIW, we don't quote the FLOPS for our current generation of hardware at all, it's that awful. We will for the next generation of it, which has (single-precision) floating point built in and will have custom accelerators for computing some key operations (exponentials and logarithms). And packs a heck of a lot more computing power in per chip too. ;)
The downside is that we'll have to redo all our numerical analysis of the algorithms in the software. There are some really subtle differences between fixed point and floating point (and I know I don't understand the details; the principles yes, but the consequences…? Nope!).
-
@Tsaukpaetra I don't know. But I do know that Windows does not function without .NET.
-
@dkf said in Software disenchantment:
We will for the next generation of it, which has (single-precision) floating point built in
Are you going for full IEEE 754 with all the whistles and bells (rounding modes, special values, etc), or just the basic 24.8 floating point format?
There are some really subtle differences between fixed point and floating point
Yeah ... that's one way to put it. I guess you're right -- there are probably a bunch of rather subtle issues once you get past the not-so-subtle, punch-you-right-in-the-face-while-looking-you-in-the-eye issues.
-
@pie_flavor said in Software disenchantment:
@Tsaukpaetra I don't know. But I do know that Windows does not function without .NET.
Which is my point. There's a shitton of stuff that's not there because it's literally required to run the OS, it's there because it's nice to have "just in case". Like, 4K resolution pictures for icons "in case I get a 4K monitor" for example. How much stuff is in the base image for backwards compatibility for those "You might want to run this 16-bit installer" programs?
-
@cvi said in Software disenchantment:
Are you going for full IEEE 754 with all the whistles and bells (rounding modes, special values, etc), or just the basic 24.8 floating point format?
Don't know. I know that the majority of functionality comes with the basic CPU core we're using (a much newer model than our current one) and our accelerators aren't standardised anyway.
once you get past the not-so-subtle, punch-you-right-in-the-face-while-looking-you-in-the-eye issues
Yeah. The subtle ones have to do with exactly how errors are accumulated; floats have less bits of mantissa than fixed point if the fixed point scaling is right. Which is actually a fucking critical thing despite not being immediately obvious. Cumulative errors are the utter bugbear of most scientific software, and they're typically ignored by most software developers who think that it's all trivial if the types are correct. :lolnope.swf:
-
@dkf said in Software disenchantment:
The subtle ones have to do with exactly how errors are accumulated; floats have less bits of mantissa than fixed point if the fixed point scaling is right. Which is actually a fucking critical thing despite not being immediately obvious.
Yeah. Although funnily enough, you also almost have the opposite case: you can get much closer to zero with floats (after all, roughly half of the floats are in the range [-1, 1] ... maybe (-1,1), if we're going to be pedantic), which can be helpful if you want to track the errors as they accumulate -- you can actually express very small errors.
If that's more or less helpful than the guarantees / hard bounds on the errors that you get somewhat more easily with fixed-point, depends on the problem, I guess.
Cumulative errors are the utter bugbear of most scientific software, and they're typically ignored by most software developers who think that it's all trivial if the types are correct. :lolnope.swf:
Best thing ever: you've actually spent time and effort minimizing cumulative errors in your code, and then some ass slaps
-ffast-mathon it. It's rather likely that compiler will rearrange your compensated sums and whatnot and optimize them right out of existence. Not to mention that any careful ordering of operations goes right out of the window.(But it's faster!)
-
@Tsaukpaetra said in Software disenchantment:
@pie_flavor said in Software disenchantment:
@Tsaukpaetra I don't know. But I do know that Windows does not function without .NET.
Which is my point. There's a shitton of stuff that's not there because it's literally required to run the OS, it's there because it's nice to have "just in case".
Most users would get completely lost if they were missing on some installs, especially if they weren't missing on other clean installs. And Windows is made with most users in mind. Unlike Linux, which is made with only Linus Torvalds in mind.
Like, 4K resolution pictures for icons "in case I get a 4K monitor" for example.
Let's say they didn't install until you get 4K monitor. You don't have monitor, so they don't install. Then you get such monitor. There are two options:
- you get ugly ass icons until you reinstall OS or manually download them;
- the system detects you now have 4K monitor and downloads them automatically. This would require an always-on service with the sole purpose of downloading high-res icons when you upgrade monitor to bigger resolution. A service that will take about the same space on disk as the icons themselves, but also actively slow down the system all the time.
Simple things are usually much harder when you actually think about them.
How much stuff is in the base image for backwards compatibility for those "You might want to run this 16-bit installer" programs?
A dozen megabytes at best. Code is light.
-
@Gąska said in Software disenchantment:
Code is light
Which is why Windows eats several tens of gigabytes.
-
@Gąska said in Software disenchantment:
There are two options:
Ah, literally only two options, I see you've thought this through to be so accurate.
-
@blakeyrat said in Software disenchantment:
Back in the day we had HyperCard, Access, Filemaker, RealBasic, Runtime Revolution...
And they all died. There was nobody who would come and decree that they shall not be used. They died for lack of fitness. Nobody ever used them. The evolution chose something else. Crying after them is pointless. They were objectively not the right path. All you can do is think about why they failed and try to invent something better.
Now I do have a theory why they failed: they did not really take out the domain complexity due to law of leaky abstractions, so you still needed dedicated developers to work them, but once the dedicated developers understood the toolset, they realised they usually want more control anyway and the slightly faster time to first prototype isn't worth it. So far, nobody found a way to design complex non-leaky abstractions, but you are of course free to try.
-
@cvi said in Software disenchantment:
Yeah. Although funnily enough, you also almost have the opposite case: you can get much closer to zero with floats (after all, roughly half of the floats are in the range [-1, 1] ... maybe (-1,1), if we're going to be pedantic), which can be helpful if you want to track the errors as they accumulate -- you can actually express very small errors.
If that's more or less helpful than the guarantees / hard bounds on the errors that you get somewhat more easily with fixed-point, depends on the problem, I guess.It depends on the mixture of operations, and whether the errors tend to come from additions or multiplications. This is why we actually have a real numerical analyst on the project's staff…
-
@Tsaukpaetra said in Software disenchantment:
several tens of gigabytes.
Citation needed. In my experience, clean install never exceeds 10GB (and non-clean install doesn't count because half the Windows directory are caches of non-OS files).
@Tsaukpaetra said in Software disenchantment:
@Gąska said in Software disenchantment:
There are two options:
Ah, literally only two options, I see you've thought this through to be so accurate.
I did, actually. If there's some third option I missed, tell me; I'd really appreciate that.
-
-
@HardwareGeek said in Software disenchantment:
@cvi said in Software disenchantment:
if we're going to be pedantic
If? YMBNH
If we're going to be pedantic, we mite of wel be
gud an proper.
-
@Gąska said in Software disenchantment:
If there's some third option I missed, tell me; I'd really appreciate that.
Sure. Option the third: don't use raw bitmaps for your icons that look ugly when scaled to 4k. Wow, I didn't even spend a full cycle coming up with that one.
-
@Tsaukpaetra ...yeah, not having the feature at all is always an option. Didn't think of that. You got me. Unless you mean they should all switch to vector graphics?
-
@Gąska said in Software disenchantment:
@Tsaukpaetra ...yeah, not having the feature at all is always an option. Didn't think of that. You got me.
That's almost literally what I said at the beginning... What even....
-
@Tsaukpaetra what you said - or what I've understood from what you said - is that the feature shouldn't be there if you don't need it. Meaning it should still be there for those who need (or just want) it. While what you actually meant - or what I've understood you actually meant - is that 4K icons is just being wasteful and the world would be better without them.
-
@Gąska said in Software disenchantment:
@Tsaukpaetra what you said - or what I've understood from what you said - is that the feature shouldn't be there if you don't need it. Meaning it should still be there for those who need (or just want) it. While what you actually meant - or what I've understood you actually meant - is that 4K icons is just being wasteful and the world would be better without them.
No, I meant the prior.
I'm envisioning something like packages. You have a graphics card? Install the graphics card package. You don't? Oh, no need for a 692mb "just in case" bundle just waiting to be unwrapped. Don't use a dot matrix printer from the 90s? Culled! Those SCSI cards? Insert disk to continue. And that's just drivers, I'm sure bigger cruft could be removed if you really tried.
Microsoft already has something like this for .Net 2 and 3 apps, and the NTVDM subsystem (on 32 bit versions) similarly installs on-demand from the Internet.
Point is that this already exists and should be intelligently taken advantage of.
-
@Tsaukpaetra said in Software disenchantment:
@pie_flavor said in Software disenchantment:
@Tsaukpaetra I don't know. But I do know that Windows does not function without .NET.
Which is my point. There's a shitton of stuff that's not there because it's literally required to run the OS, it's there because it's nice to have "just in case". Like, 4K resolution pictures for icons "in case I get a 4K monitor" for example. How much stuff is in the base image for backwards compatibility for those "You might want to run this 16-bit installer" programs?
How is that your point? The GUIs are written in XAML. Therefore .NET is used to run Windows. You can say you have a point, but don't say that your example had anything to do with it, because it didn't.
-
@pie_flavor said in Software disenchantment:
@Tsaukpaetra said in Software disenchantment:
@pie_flavor said in Software disenchantment:
@Tsaukpaetra I don't know. But I do know that Windows does not function without .NET.
Which is my point. There's a shitton of stuff that's not there because it's literally required to run the OS, it's there because it's nice to have "just in case". Like, 4K resolution pictures for icons "in case I get a 4K monitor" for example. How much stuff is in the base image for backwards compatibility for those "You might want to run this 16-bit installer" programs?
How is that your point? The GUIs are written in XAML. Therefore .NET is used to run Windows. You can say you have a point, but don't say that your example had anything to do with it, because it didn't.
I didn't mean that icons literally come in 4K resolutions .
It's going to be one of those days, isn't it?
-
@Tsaukpaetra I didn't mention icons. What's this about icons? I'm talking about you saying how .NET isn't required to run the OS. It is.
-
@pie_flavor said in Software disenchantment:
@Tsaukpaetra I didn't mention icons. What's this about icons? I'm talking about you saying how .NET isn't required to run the OS. It is.
Which is why when you attempt to run .Net 2.0 programs you must first install a Windows Feature, clearly.
And no, it's not required. I run game servers on an in-RAM version of Windows that literally has .Net ripped from it, and it performs perfectly well.
-
@Tsaukpaetra Key word there is 'servers'. You forgot to read what I said again. The GUIs are written in XAML. If you don't use GUIs then that's another story.
-
@pie_flavor said in Software disenchantment:
@Tsaukpaetra Key word there is 'servers'. You forgot to read what I said again. The GUIs are written in XAML. If you don't use GUIs then that's another story.
There's plenty of GUI. I'm doing my best to get rid of it, but doing so seems to mean moving to Linux, and even then it's not a guarantee, and even then I have to get Microsoft stuff working inside Linux, and even then...
-
@Tsaukpaetra What happens if you open Settings?
