I don't see how the heck anything can hit production without there being at least a token trail to show what went wrong, if not a full blown change approval process. Everything depends on criticality of the system. If all that's going to happen is that a few people will be unhappy and you'll be sweating for a couple of minutes (likely case in many small businesses), then having full audit trail, change management and rollbacks is all it takes. If 10,000 people will be left waiting at their ATMs, there better be a couple of pairs of eyes to take a look, never mind tests etc.
I do engineering risk management as part of my job. All I know is that humans mess up. Routinely. It's guaranteed by design. Processes are in place to mitigate the human propensity for fuckups. Human at the console is, by design, way more likely to fuck up than a human writing a script that will go through at least some process before it even hits the test stands. On a console, you hit enter and go "fuck, now I have to roll back". Writing a script, you take a bathroom break, come back, look at it again while working on the 1-page spec, and you realize "hey, I better make sure this and that won't happen".
What you don't understand or just seem intentionally obtuse about is that change and release management applies to the entirety of the process, whether manual, scripted, done by robots, quantum computers, mercury memory lines, million monkeys, or what the heck ever. It doesn't matter if it's done by a script or a $10/hr intern typing the same thing on a thousand consoles. It must be subject to the same process. Once that's clear, I don't see how scripting and manual process differ, besides burning coal vs. carbohydrates.
So if a sysadmin does it manually with all the risk of mistakes it entails, that's fine and dandy, but if they dare write code for it, only then it's subject to the holy process? LOL.
Who says the sysadmins are playing with production systems? The sysadmins may code simply to automate their lives, for example. They may code so that they can gather statistics, or configure things, etc. The development and deployment lifecycle sure as heck is needed, but your whole company is probably not subject to it, and even if it were, whatever the sysadmins manually do would be subject to the same process, so whether it's done manually or automated doesn't matter -- auditing etc. is exactly the same.
I am such a "responsible for a bunch of shit guy" and these days I pretty much work on solutions to make myself obsolete and available for other work. This includes developing a bunch of software and even hardware to replace various manual processes that ultimately were only as good (or bad) as I was. Where quality is concerned in manufacturing, an automated task always beats my performance, at least in my job. I'd have thought everyone in a similar position would realize this, and the fact that them being irreplaceable isn't good for themselves or the company they work for. Being irreplaceable means you can't do what you'd want or even anything related to what the business may need in the future. It keeps you focused on here and there and it's easy to lose perspective that way. It's hard to innovate while being irreplaceable, I'd think, or at least when you're intermingled in day-to-day operation so that it distracts from "futuristic" projects you may wish to undertake.
The "abomination in VBA" may be so, but it has likely replaced tons of manual labor. When it outgrows the original author's skills, then there's no reason not to do a proper reimplementation. Yet all those abominations, usually, make their authors more productive. That's their goal. Scoffing at that is going full retard.
I think that these days programming is like being literate. Sure you don't really need to know how to read and write, your secretary can do it for you all day long. It just seems like a big waste of effort to me. For many simple and repetitive things related to their jobs, everyone should be able to whip up a quick script, just like everyone takes notes as needs arise, without calling their secretary on the intercom every time they need to write down a phone number.
It's a photo frame for crying out loud. If it doesn't work, you can perhaps fix it. If you want weather on your fireplace's mantle, punch a hole to the outside and be done, mmkay?
All those things nominally take comparatively little data to represent before they hit the rendering pipeline. Alas, with X11, VNC and RDP as they now stand, you push bitmaps around, and that sucks bandwidth like nobody's business. Wayland doesn't do enough. To be efficient at network transparency, all of the displaying needs to be done from a scene graph, and the application is then modifying the scene graph on whatever display it's being shown on. That's taking what made X11 well performing back in the day to the logical conclusion. Sure as heck you'll need some decent resources on the display, as plenty of heavy lifting is done there, but hey, that's distributed computing for you. Web browsers do the same, web would grind to a halt if servers had to render everything for the surfers...
Even displaying video on such a decently designed system should be pushing compressed video stream to the display node, as that takes obviously much less bandwidth than the decompressed stream. If you're compositing some controls over the video, they will be in the scene graph and the display will do all the magic needed for it to show as intended. The bandwidth needed for that is equal to the bandwidth for the video stream -- compare that to the staggering pipe X11, VNC and RDP would need for the same functionality.
Existing X11 apps? Pray tell, what would those be? Does anyone care about xeyes anymore? I mean, I'd have thought that everything of note uses a framework/library of some sort that abstracts X11 away? Sure you need to port the framework, but the applications won't even know anything changed...
Because any X application that doesn't render using OpenGL can't really do much else than generate bitmaps and blit them to the screen if you're expecting any modern style of UI (vs. legacy polygons and arcs only). Since everyone and their grandma reinvents various layers of those bitmap-making functionality over an over, it all looks like crap and performs like crap. It's hard for developers to focus on making things look good when the platform they develop on (X + various libraries that sit on top of it) performs poorly, is buggy, and often is fragmented as hell and lacks cohesion. Higher-level all-in-one frameworks like Qt at least try to provide one design for the entire stack, whether you want to paint just a line or a whole scene. When you get into GTK land, there's a bazillion pieces all done by different people. Other frameworks, like Tk or wxWidgets, are a bit behind the times in their capabilities and make it hard to get things to look modern.
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times. Nobody renders like that. The only way to reuse such an API to render modern UIs (without using GPU functionality) is to generate bitmaps using various modern rendering libraries and toolkits (like Qt does!) and push those to the screen. Thus, for a modern application, X11 and GDI are bitblt and input with lots of other junk nobody cares about. Yeah, X servers were working fine on resource constrained Unix systems 20 years ago, but then the UIs back then consisted of relatively simple primitives that the X server could actually draw. These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.
The legacy APIs are useless, they don't scale anymore. Back in times of X, any application that drew anything complex had to maintain its own scene graph of some sort and maintain its own space partitioning to choose what to redraw. This led to obscene duplication of effort, and various applications had their own glitches, shortcomings and inefficiencies because everyone was reimplementing what wasn't all that easy to implement correctly in the first place.
Given the graphics hardware available today, those legacy APIs of GDI and X vintage expose a model that is so far detached from how the hardware processes the geometry, that applications that merely use the API can't leverage the available graphics horsepower. IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.
When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.
It goes the other way: unless you design for network transparency from day one, you're not going to get it and have it perform well. There's no way to decently get network transparency as a layer on top of the window system. VNC and RDP are horrible kludges and perform like crap.
Once there's slip, it doesn't matter if they're locked up or not.
Well, some special muddy/snowy conditions notwithstanding. That's why it's silly that there aren't ABS mode switches that'd tailor the response to actual conditions. I guess with some idiot drivers unable to turn their lights on correctly, that'd make things worse, not better. What I mean is that all too often I see people driving at night with only position lights turned on:(
OK, I missed that important detail. There's no magic in keeping the wheels rolling while slipping, though. Once there's slip, it doesn't matter if they're locked up or not. Dynamic friction doesn't care much about what's the velocity difference -- once there's enough of it, it doesn't matter anymore. Of course keeping the wheel rolling means that recovery from the slip will be faster than if the wheel was locked up: if the friction force is constant, then it'll simply take less time to transfer the smaller energy needed to speed up a wheel that has non-zero rotational velocity. Decent ABS systems try to maintain such limited slip, thus the more slippery the surface you're on, the higher pitched will the brake modulation be, as brake force gets to be applied for shorter periods of time. Best ABS systems use periodic modulation only for measurement of slip and maintain arbitrary braking force, adjusted by the results of the said measurements. It's like if you applied just enough brake pressure, and wiggled your foot a bit to see if you could apply more by any chance. I don't know offhand who does it that way, as it'd be considered state of the art at the moment.
Shear stresses in the tire material have got nothing to do with where you are driving, and cornering is absolutely irrelevant to this discussion. Don't mix up shear contact forces with shear stresses. Those two got nothing to do with each other!!! Remember: a stress is a property defined at a point in the material, and there's generally 6 numbers needed to completely describe stress state at a point (plus another 3 numbers to describe what orientation is your stress state described in).
Someone messed up with that SD controller driver -- they must have had no clue what they were doing. Seriously. I mean, give me a break, Linux has very nice high resolution kernel timers, you can pretty much schedule your driver to resume some time later with microsecond resolution and quite good repeatability. Never mind that with USB everything is done in chunks that are paced by the frame metronome at 1ms. There is no reason to react at any other time base but that of the USB frame, because no matter what you do, the request will get scheduled to be done at the next frame with some bandwidth still left. Basically, when writing USB device drivers (as opposed to host drivers) all you do is react to completion and/or progress of your queued USB requests, and any timing you can do is needs 1ms resolution and that's it.
Given that USB runs on a fixed schedule like any hard-realtime PLC would, and doesn't require any excessive interrupt-time processing, I don't have the slightest idea WTF you're after. FUD much? If you're transmitting via USB to, say, any FTDI chip, then it's quite trivial to update the outputs on a rock solid 1ms timebase (or an integer multiple of that period). Given that, it's quite easy to maintain streaming for various bit-bang modes that modern FTDI chips support.
Ah, under copyright laws in plenty of jurisdictions, the copyright in derivative works is usually shared by both the original holders and the authors of derivative works. Yes, you can quite happily copyright an unauthorized translation. It doesn't let you distribute it or do anything else really, but you can claim copyright in it all right. So, yes, funnily enough, both original copyright holders and the translators share copyright on the translations. Any copying requires permission from both. So just because it's an unauthorized translation doesn't mean that the original rights holders can claim the translation as their own. Such a translation is in limbo, in a way.
The product itself has to be reengineered, but it's little internal details, not the overall weight, form, and function. Not every bit of consumer electronics is made this way. Sony's Walkmans were and Swatch watches are IIRC done 100% automated, hands-off.
Slashdot Mirror
I don't see how the heck anything can hit production without there being at least a token trail to show what went wrong, if not a full blown change approval process. Everything depends on criticality of the system. If all that's going to happen is that a few people will be unhappy and you'll be sweating for a couple of minutes (likely case in many small businesses), then having full audit trail, change management and rollbacks is all it takes. If 10,000 people will be left waiting at their ATMs, there better be a couple of pairs of eyes to take a look, never mind tests etc.
I do engineering risk management as part of my job. All I know is that humans mess up. Routinely. It's guaranteed by design. Processes are in place to mitigate the human propensity for fuckups. Human at the console is, by design, way more likely to fuck up than a human writing a script that will go through at least some process before it even hits the test stands. On a console, you hit enter and go "fuck, now I have to roll back". Writing a script, you take a bathroom break, come back, look at it again while working on the 1-page spec, and you realize "hey, I better make sure this and that won't happen".
Oh, you mean, like a total re-specification, re-design and re-implementation? Then I think we agree :)
What you don't understand or just seem intentionally obtuse about is that change and release management applies to the entirety of the process, whether manual, scripted, done by robots, quantum computers, mercury memory lines, million monkeys, or what the heck ever. It doesn't matter if it's done by a script or a $10/hr intern typing the same thing on a thousand consoles. It must be subject to the same process. Once that's clear, I don't see how scripting and manual process differ, besides burning coal vs. carbohydrates.
So if a sysadmin does it manually with all the risk of mistakes it entails, that's fine and dandy, but if they dare write code for it, only then it's subject to the holy process? LOL.
Who says the sysadmins are playing with production systems? The sysadmins may code simply to automate their lives, for example. They may code so that they can gather statistics, or configure things, etc. The development and deployment lifecycle sure as heck is needed, but your whole company is probably not subject to it, and even if it were, whatever the sysadmins manually do would be subject to the same process, so whether it's done manually or automated doesn't matter -- auditing etc. is exactly the same.
I am such a "responsible for a bunch of shit guy" and these days I pretty much work on solutions to make myself obsolete and available for other work. This includes developing a bunch of software and even hardware to replace various manual processes that ultimately were only as good (or bad) as I was. Where quality is concerned in manufacturing, an automated task always beats my performance, at least in my job. I'd have thought everyone in a similar position would realize this, and the fact that them being irreplaceable isn't good for themselves or the company they work for. Being irreplaceable means you can't do what you'd want or even anything related to what the business may need in the future. It keeps you focused on here and there and it's easy to lose perspective that way. It's hard to innovate while being irreplaceable, I'd think, or at least when you're intermingled in day-to-day operation so that it distracts from "futuristic" projects you may wish to undertake.
The "abomination in VBA" may be so, but it has likely replaced tons of manual labor. When it outgrows the original author's skills, then there's no reason not to do a proper reimplementation. Yet all those abominations, usually, make their authors more productive. That's their goal. Scoffing at that is going full retard.
I think that these days programming is like being literate. Sure you don't really need to know how to read and write, your secretary can do it for you all day long. It just seems like a big waste of effort to me. For many simple and repetitive things related to their jobs, everyone should be able to whip up a quick script, just like everyone takes notes as needs arise, without calling their secretary on the intercom every time they need to write down a phone number.
It's a photo frame for crying out loud. If it doesn't work, you can perhaps fix it. If you want weather on your fireplace's mantle, punch a hole to the outside and be done, mmkay?
All those things nominally take comparatively little data to represent before they hit the rendering pipeline. Alas, with X11, VNC and RDP as they now stand, you push bitmaps around, and that sucks bandwidth like nobody's business. Wayland doesn't do enough. To be efficient at network transparency, all of the displaying needs to be done from a scene graph, and the application is then modifying the scene graph on whatever display it's being shown on. That's taking what made X11 well performing back in the day to the logical conclusion. Sure as heck you'll need some decent resources on the display, as plenty of heavy lifting is done there, but hey, that's distributed computing for you. Web browsers do the same, web would grind to a halt if servers had to render everything for the surfers...
Even displaying video on such a decently designed system should be pushing compressed video stream to the display node, as that takes obviously much less bandwidth than the decompressed stream. If you're compositing some controls over the video, they will be in the scene graph and the display will do all the magic needed for it to show as intended. The bandwidth needed for that is equal to the bandwidth for the video stream -- compare that to the staggering pipe X11, VNC and RDP would need for the same functionality.
Existing X11 apps? Pray tell, what would those be? Does anyone care about xeyes anymore? I mean, I'd have thought that everything of note uses a framework/library of some sort that abstracts X11 away? Sure you need to port the framework, but the applications won't even know anything changed...
Because any X application that doesn't render using OpenGL can't really do much else than generate bitmaps and blit them to the screen if you're expecting any modern style of UI (vs. legacy polygons and arcs only). Since everyone and their grandma reinvents various layers of those bitmap-making functionality over an over, it all looks like crap and performs like crap. It's hard for developers to focus on making things look good when the platform they develop on (X + various libraries that sit on top of it) performs poorly, is buggy, and often is fragmented as hell and lacks cohesion. Higher-level all-in-one frameworks like Qt at least try to provide one design for the entire stack, whether you want to paint just a line or a whole scene. When you get into GTK land, there's a bazillion pieces all done by different people. Other frameworks, like Tk or wxWidgets, are a bit behind the times in their capabilities and make it hard to get things to look modern.
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times. Nobody renders like that. The only way to reuse such an API to render modern UIs (without using GPU functionality) is to generate bitmaps using various modern rendering libraries and toolkits (like Qt does!) and push those to the screen. Thus, for a modern application, X11 and GDI are bitblt and input with lots of other junk nobody cares about. Yeah, X servers were working fine on resource constrained Unix systems 20 years ago, but then the UIs back then consisted of relatively simple primitives that the X server could actually draw. These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.
The legacy APIs are useless, they don't scale anymore. Back in times of X, any application that drew anything complex had to maintain its own scene graph of some sort and maintain its own space partitioning to choose what to redraw. This led to obscene duplication of effort, and various applications had their own glitches, shortcomings and inefficiencies because everyone was reimplementing what wasn't all that easy to implement correctly in the first place.
Given the graphics hardware available today, those legacy APIs of GDI and X vintage expose a model that is so far detached from how the hardware processes the geometry, that applications that merely use the API can't leverage the available graphics horsepower. IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.
When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.
It goes the other way: unless you design for network transparency from day one, you're not going to get it and have it perform well. There's no way to decently get network transparency as a layer on top of the window system. VNC and RDP are horrible kludges and perform like crap.
Ta-da. You can even leverage the firewall on Linux to only open the necessary holes etc.
This could be probably made to work on a Linux host with almost any virtualization solution out there (KVM, VMware, VirtualBox) :)
Once there's slip, it doesn't matter if they're locked up or not.
Well, some special muddy/snowy conditions notwithstanding. That's why it's silly that there aren't ABS mode switches that'd tailor the response to actual conditions. I guess with some idiot drivers unable to turn their lights on correctly, that'd make things worse, not better. What I mean is that all too often I see people driving at night with only position lights turned on :(
OK, I missed that important detail. There's no magic in keeping the wheels rolling while slipping, though. Once there's slip, it doesn't matter if they're locked up or not. Dynamic friction doesn't care much about what's the velocity difference -- once there's enough of it, it doesn't matter anymore. Of course keeping the wheel rolling means that recovery from the slip will be faster than if the wheel was locked up: if the friction force is constant, then it'll simply take less time to transfer the smaller energy needed to speed up a wheel that has non-zero rotational velocity. Decent ABS systems try to maintain such limited slip, thus the more slippery the surface you're on, the higher pitched will the brake modulation be, as brake force gets to be applied for shorter periods of time. Best ABS systems use periodic modulation only for measurement of slip and maintain arbitrary braking force, adjusted by the results of the said measurements. It's like if you applied just enough brake pressure, and wiggled your foot a bit to see if you could apply more by any chance. I don't know offhand who does it that way, as it'd be considered state of the art at the moment.
Shear stresses in the tire material have got nothing to do with where you are driving, and cornering is absolutely irrelevant to this discussion. Don't mix up shear contact forces with shear stresses. Those two got nothing to do with each other!!! Remember: a stress is a property defined at a point in the material, and there's generally 6 numbers needed to completely describe stress state at a point (plus another 3 numbers to describe what orientation is your stress state described in).
Someone messed up with that SD controller driver -- they must have had no clue what they were doing. Seriously. I mean, give me a break, Linux has very nice high resolution kernel timers, you can pretty much schedule your driver to resume some time later with microsecond resolution and quite good repeatability. Never mind that with USB everything is done in chunks that are paced by the frame metronome at 1ms. There is no reason to react at any other time base but that of the USB frame, because no matter what you do, the request will get scheduled to be done at the next frame with some bandwidth still left. Basically, when writing USB device drivers (as opposed to host drivers) all you do is react to completion and/or progress of your queued USB requests, and any timing you can do is needs 1ms resolution and that's it.
Given that USB runs on a fixed schedule like any hard-realtime PLC would, and doesn't require any excessive interrupt-time processing, I don't have the slightest idea WTF you're after. FUD much? If you're transmitting via USB to, say, any FTDI chip, then it's quite trivial to update the outputs on a rock solid 1ms timebase (or an integer multiple of that period). Given that, it's quite easy to maintain streaming for various bit-bang modes that modern FTDI chips support.
Ah, under copyright laws in plenty of jurisdictions, the copyright in derivative works is usually shared by both the original holders and the authors of derivative works. Yes, you can quite happily copyright an unauthorized translation. It doesn't let you distribute it or do anything else really, but you can claim copyright in it all right. So, yes, funnily enough, both original copyright holders and the translators share copyright on the translations. Any copying requires permission from both. So just because it's an unauthorized translation doesn't mean that the original rights holders can claim the translation as their own. Such a translation is in limbo, in a way.
This demands a, 0, Whoosh, moderation :)
The product itself has to be reengineered, but it's little internal details, not the overall weight, form, and function. Not every bit of consumer electronics is made this way. Sony's Walkmans were and Swatch watches are IIRC done 100% automated, hands-off.