Looking for links to the Sage 50 (formerly Peachtree) SDK turned up this link with a few different leads. Agree with what you've said about the focus on a ridiculous upgrade treadmill. One of my clients continues to use QB Pro 2000 to this day.
Parking lights are surprisingly bright too. Someone I know hit a deer that took out both headlights on a back country road, but the parking lights were still working. They drove home just fine on hazard blinkers.
The problem comes when UI becomes UX. It's not about the discoverability, consistency, and relative ease of use anymore, it's all about bullshit like "minimalist design" (which is the absolute opposite of how a program that has hundreds of possible functions should be set up) and "ease of use" where the person designing the stuff thinks "ease" comes from hiding all the controls, lowering contrast between UI elements, throwing out menu bars, requiring complex "gestures" to perform simple tasks, and shrinking or eliminating hints that allow discovery of the now-hidden functionality
This is what happens when catering to the lowest common denominator and trying to make a name for yourself by rewriting what has worked fantastically for decades become acceptable and common in society. UX "design" is the Common Core Math of UI design. When I see GNOME 3, I see "subtraction sentences."
"Your solution is personalized to your experience, and all of your conclusions are based on your knowledge and behavior."
Uh, no kidding. Do you expect me to produce peer-reviewed studies or something? Do you think that my experience is invalid? Do you expect me to conduct extensive research before posting a Slashdot comment? Am I supposed to be able to know everyone else's sum total of life experience and relative skill levels before I'm allowed to post some thoughts to encourage more constructive feedback than "hurr durr fucking idiots should stop texting and driving"?
What's your solution to the problem? Remember that since you've implied that "conclusions based on personal experience, knowledge, and behavior" are automatically insufficient, you'll need to present a much more significant chunk of information to back it up than your own personal experience, knowledge, and behavior.
You have contributed nothing to this discussion other than berating me and making a straw man argument about 16-year-olds, and I don't see how your post is in any way productive.
Fuck 'em. They made the desktop environment require the monstrosity that is systemd, so I don't care if they go away entirely. GNOME was decent in the 2 series, though still never managed to not be buggy; when they moved to 3, everything went downhill HARD. Terrible UI changes that almost no one wanted, and then forcing systemd as a required dependency.
You did it to yourselves. Go become irrelevant. Viva la Fluxbox!
When I had a T-Mobile G1 phone with the lovely five-row hardware keyboard AND prior to "no texting and driving" laws going into place, I could cruise down a highway with low to moderate traffic, texting away for the entire ride, and still watch everything going on around me. I did this regularly. I could see every brake light and every erratic movement. I could also easily drop my phone and jerk the wheel if someone nearby got way too unstable. I'd hold the phone at the top of the wheel with both hands on the wheel and the phone at the same time, and my field of view included both the tiny phone screen and the massive windshield.
Hardware keyboards made this relatively safe, as I could type text very accurately without looking except to check periodically. No five-second distractions. On-screen keyboards ruined this; now I have to deal with an inaccurate touchscreen and pray that my auto-correction works properly (and that I didn't hit a letter that auto-corrected to the wrong word!) Texting while driving became a traffic ticket, on top of the demise of the hardware keyboard. Now I can't text at all; it's not safe because I'd have to hide it and on-screen keyboards are difficult to use without a great deal of focus.
People don't stop texting while driving when it's illegal. They get smart and do the texting well out of view of an officer, which means you have the long distraction of on-screen keyboards and looking far away from your driving environment to read and write combined. The perfect storm of texting while driving, and it's the drive for thin phones and banning texting while driving that caused it. Then cops do this shit which illustrates the utter ridiculousness of the situation. If you have to buy big pimpin' SUVs to catch people texting while driving, maybe you should consider whether you're attacking the root of the problem or just one of the symptoms.
You can't stop people from texting while driving, so my solution is as follows. Drivers would need to not text when in heavy traffic or poor weather, which I think is really stupid in the first place and should be common sense. Phones need to return to slide-out 4-5 row hardware keyboards which allow the typing to happen without requiring concentration on it. Texting while driving should be made legal as long as it happens in such a way that the driver's eyes are still within the general "windshield field of view" while doing it, which means hands would have to be on the wheel and peripheral vision would be doing its job.
This would be the safest combination. You will never stop people from texting while driving. Punishment is not a deterrent. No one thinks they're going to get in trouble for minor shit like this until they actually do; why not greatly reduce the risk involved instead of increasing it with laws that ban it? Then again, they still haven't understood this concept about marijuana and other currently illegal drugs, so I suppose we should expect no less.
Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot. The BIOS slowness was mostly due to heaps of unnecessary memory tests and diagnostics anyway. Once those stop happening, there's not much time spent getting ready for booting at all. Windows 7 on my Windows 8-shipped laptop with an SSD comes up to a ready-to-go desktop in less than 10 seconds from power on. The BIOS speed obstacle is largely solved on new machines.
If SSL was tightly regulated, free SSL stacks wouldn't be provided anymore; also, government control over the encryption available to the public is always a bad thing.
OpenSSL is offered with no warranty, is completely free of charge, and numerous alternatives (free and proprietary) exist. The programmers are not responsible for what other people ultimately do with the source code they offer. There is no way to hold the OpenSSL programmers responsible for this. The person deploying the actual library into production use would be the one that is ultimately responsible.
Using your analogy, free software like OpenSSL would be under the "good samaritan" laws. If someone attempts to sew you up in the field to stop bleeding but the stitches fail and you bleed out and die anyway, that person wouldn't be held responsible for killing you since they were attempting to help you as best as they could and you'd have died otherwise. If you don't use a SSL stack, you have no encryption. OpenSSL programmers are good samaritans, but OpenSSL is not offered with any guarantee that it will be useful, you don't have to use it (there are many cipher suites), and since it's open, the user can audit it for themselves. One could argue, "why didn't the millions of users of the code audit the code before using it? When do we hold our hosting providers and banks responsible?"
A doctor performing surgery or an engineer designing a manufacturing machine (both at significant expense to the customer) are quite different from using something you got completely for free with full design schematics an upfront "there is no guarantee that this will work but we hope you find it useful" warning and that free thing leaking its contents for some reason.
In retrospect these bugs look so simple and stupid to casual observers, but programmers know that simplistic hindsight shoulda-woulda-coulda analysis such as "oh, it only needed a simple bounds check!" and "you should have removed that goto line while you were working on that code!" only shows a gross lack of understanding of what real-world programming is like. It's easy to forget a simple bounds check; hell, it's a miracle a programmer gets anything done at all with all of the variables and structs and malloc() calls and pointers that have to be memorized. I recently wrote the code for adding undo support for BusyBox vi, and I can tell you firsthand that what seems like a simple thing (store changes, undo them) is a complicated and frustrating process once you start in on it. Even after I made simple undo actions work, the challenges compounded when I added the "intermediate queuing" enhancement to lower the otherwise insane malloc() overhead and improve the overall behavior of my "simplest thing that could possibly work" code.
The process of dissolving a big problem into low-level steps as is required by C programming is mentally brutal. You can't just go "I want to save the text that was deleted and restore it when they hit the undo key." You have to translate that into variables, pointers, structs, mallocs, and glue logic. You have to take into account every corner case; how do you undo multiple lines of pasted text instead of single characters? How do you store undo information a paste-over operation, where you must keep a record of what was deleted but also record that it overwrites a (possibly different length) chunk of the text buffer? How do you store the undo data for find-and-replace operations? Now that you've managed to figure out ways to store all these different types of text editing operations for undoing, how do you actually undo each one? Where does all this stuff need to hook into the existing program, and how will you hook it in without breaking existing functionality?
It's so easy to forget trivially simple things when you're trying to flow your mind through that complex glue logic that makes the magic happen, especially when you make a change, it appears to work, and you have no way to test for the bug you created by accidental error or omission.
GnuTLS exists. NSS (and NSPR [Netscape Portable Runtime] which is a hard dependency) used to have to be extracted from Mozilla source code to compile too. It was really ridiculous when I compiled it for the first time. GnuTLS is (A) not OpenSSL and (B) doesn't require NSPR. There are also OpenSSL drop-in replacements that work well, such as CyaSSL.
Programmers make these kinds of mistakes all the time. It's not uncommon. The problem is that a mistake in a text editor "undo" function is nowhere near as big of a security issue as such a mistake in a network-connected cryptography library.
Look at the recent Apple security hole: all they did was leave in a redundant "goto" statement that unfortunately had the effect of negating the purpose of the previous check and opening a hole. It could have been as simple as not deleting the line due to a distraction somewhere else in the code, and it likely passed all the unit tests (can't easily write a test for all of these types of mistakes.)
Programmers are human. They'll make a ton of mistakes. I can't say I blame him for making one; anyone who has written enough C code is used to making plenty of mistakes before something usable comes out the other end.
I appreciate what you're saying. I would like to add that diversity of viewpoints isn't necessarily achieved through diversity of skin color or gender (though there are undeniable socioeconomic forces out there that are race- and gender-heavy); viewpoints, quite literally, are all in a person's head. The value of viewpoint diversity is also dependent on what task is being performed. If someone is exclusively performing research and gathering hard data, diversity of viewpoints is of negligible value; if they're designing a product for public consumption, diversity of viewpoints is often more valuable than gold and can make or break the product.
I agree with your assessment, and I question those who would consider it sexist. Fortunately, I have observed a slow but steady correction trend in response to the constant flow of news about sexism in tech, and once naive people in tech are wising up to the games and expressing a sentiment of "sexism should be fought regardless of where it comes from, assholes are assholes whether they're men or not, and people should be free to make their choices without having to base it on their bodies." There is hope for the future.
There is no intrinsic value in someone's bodily traits that they cannot control, so "male and pale" are irrelevant factors for indoor jobs that aren't physically demanding. Adding vaginas and darker skin (or subtracting the same) has no effect to the ability to write code, create procedure analysis reports, put toothpase tubes in boxes, or use a microscope. Gender parity is flat-out irrelevant from the standpoint of hiring someone in a business to perform specific tasks.
Here's another interesting way to examine it: in "gender-dominated job" arguments, replace "male/female" with "tall/short" and see how the emotions change. Gender naturally being a binary trait only makes it lower-hanging fruit for an "us vs. them" discrimination war, but perhaps there aren't enough short people in tech either! Why aren't we seeing a "more short people in tech initiative?" People are just as likely to be discriminated against for their height as their gender.
Slashdot Mirror
Looking for links to the Sage 50 (formerly Peachtree) SDK turned up this link with a few different leads. Agree with what you've said about the focus on a ridiculous upgrade treadmill. One of my clients continues to use QB Pro 2000 to this day.
I'm interested in this and would like to hear more about it. G+ link in title.
*dodge* Oh shit, I almost got hit by facts! Whew. (seriously though, great perspective illustration.)
Fast Hack'Em was a truly awesome program (well, technically it was a suite of programs). I almost forgot about it; it's really been a while.
Parking lights are surprisingly bright too. Someone I know hit a deer that took out both headlights on a back country road, but the parking lights were still working. They drove home just fine on hazard blinkers.
[citation needed]
The problem comes when UI becomes UX. It's not about the discoverability, consistency, and relative ease of use anymore, it's all about bullshit like "minimalist design" (which is the absolute opposite of how a program that has hundreds of possible functions should be set up) and "ease of use" where the person designing the stuff thinks "ease" comes from hiding all the controls, lowering contrast between UI elements, throwing out menu bars, requiring complex "gestures" to perform simple tasks, and shrinking or eliminating hints that allow discovery of the now-hidden functionality
This is what happens when catering to the lowest common denominator and trying to make a name for yourself by rewriting what has worked fantastically for decades become acceptable and common in society. UX "design" is the Common Core Math of UI design. When I see GNOME 3, I see "subtraction sentences."
"Your solution is personalized to your experience, and all of your conclusions are based on your knowledge and behavior."
Uh, no kidding. Do you expect me to produce peer-reviewed studies or something? Do you think that my experience is invalid? Do you expect me to conduct extensive research before posting a Slashdot comment? Am I supposed to be able to know everyone else's sum total of life experience and relative skill levels before I'm allowed to post some thoughts to encourage more constructive feedback than "hurr durr fucking idiots should stop texting and driving"?
What's your solution to the problem? Remember that since you've implied that "conclusions based on personal experience, knowledge, and behavior" are automatically insufficient, you'll need to present a much more significant chunk of information to back it up than your own personal experience, knowledge, and behavior.
You have contributed nothing to this discussion other than berating me and making a straw man argument about 16-year-olds, and I don't see how your post is in any way productive.
Not sure if trolling...or just lazy
Fuck 'em. They made the desktop environment require the monstrosity that is systemd, so I don't care if they go away entirely. GNOME was decent in the 2 series, though still never managed to not be buggy; when they moved to 3, everything went downhill HARD. Terrible UI changes that almost no one wanted, and then forcing systemd as a required dependency.
You did it to yourselves. Go become irrelevant. Viva la Fluxbox!
When I had a T-Mobile G1 phone with the lovely five-row hardware keyboard AND prior to "no texting and driving" laws going into place, I could cruise down a highway with low to moderate traffic, texting away for the entire ride, and still watch everything going on around me. I did this regularly. I could see every brake light and every erratic movement. I could also easily drop my phone and jerk the wheel if someone nearby got way too unstable. I'd hold the phone at the top of the wheel with both hands on the wheel and the phone at the same time, and my field of view included both the tiny phone screen and the massive windshield.
Hardware keyboards made this relatively safe, as I could type text very accurately without looking except to check periodically. No five-second distractions. On-screen keyboards ruined this; now I have to deal with an inaccurate touchscreen and pray that my auto-correction works properly (and that I didn't hit a letter that auto-corrected to the wrong word!) Texting while driving became a traffic ticket, on top of the demise of the hardware keyboard. Now I can't text at all; it's not safe because I'd have to hide it and on-screen keyboards are difficult to use without a great deal of focus.
People don't stop texting while driving when it's illegal. They get smart and do the texting well out of view of an officer, which means you have the long distraction of on-screen keyboards and looking far away from your driving environment to read and write combined. The perfect storm of texting while driving, and it's the drive for thin phones and banning texting while driving that caused it. Then cops do this shit which illustrates the utter ridiculousness of the situation. If you have to buy big pimpin' SUVs to catch people texting while driving, maybe you should consider whether you're attacking the root of the problem or just one of the symptoms.
You can't stop people from texting while driving, so my solution is as follows. Drivers would need to not text when in heavy traffic or poor weather, which I think is really stupid in the first place and should be common sense. Phones need to return to slide-out 4-5 row hardware keyboards which allow the typing to happen without requiring concentration on it. Texting while driving should be made legal as long as it happens in such a way that the driver's eyes are still within the general "windshield field of view" while doing it, which means hands would have to be on the wheel and peripheral vision would be doing its job.
This would be the safest combination. You will never stop people from texting while driving. Punishment is not a deterrent. No one thinks they're going to get in trouble for minor shit like this until they actually do; why not greatly reduce the risk involved instead of increasing it with laws that ban it? Then again, they still haven't understood this concept about marijuana and other currently illegal drugs, so I suppose we should expect no less.
Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot. The BIOS slowness was mostly due to heaps of unnecessary memory tests and diagnostics anyway. Once those stop happening, there's not much time spent getting ready for booting at all. Windows 7 on my Windows 8-shipped laptop with an SSD comes up to a ready-to-go desktop in less than 10 seconds from power on. The BIOS speed obstacle is largely solved on new machines.
If SSL was tightly regulated, free SSL stacks wouldn't be provided anymore; also, government control over the encryption available to the public is always a bad thing.
You're asking me to defend an analogy that is intentionally based on the flawed premises in its parent post; I don't see how that would be helpful.
Plenty of these have already happened.
OpenSSL is offered with no warranty, is completely free of charge, and numerous alternatives (free and proprietary) exist. The programmers are not responsible for what other people ultimately do with the source code they offer. There is no way to hold the OpenSSL programmers responsible for this. The person deploying the actual library into production use would be the one that is ultimately responsible.
Using your analogy, free software like OpenSSL would be under the "good samaritan" laws. If someone attempts to sew you up in the field to stop bleeding but the stitches fail and you bleed out and die anyway, that person wouldn't be held responsible for killing you since they were attempting to help you as best as they could and you'd have died otherwise. If you don't use a SSL stack, you have no encryption. OpenSSL programmers are good samaritans, but OpenSSL is not offered with any guarantee that it will be useful, you don't have to use it (there are many cipher suites), and since it's open, the user can audit it for themselves. One could argue, "why didn't the millions of users of the code audit the code before using it? When do we hold our hosting providers and banks responsible?"
A doctor performing surgery or an engineer designing a manufacturing machine (both at significant expense to the customer) are quite different from using something you got completely for free with full design schematics an upfront "there is no guarantee that this will work but we hope you find it useful" warning and that free thing leaking its contents for some reason.
In retrospect these bugs look so simple and stupid to casual observers, but programmers know that simplistic hindsight shoulda-woulda-coulda analysis such as "oh, it only needed a simple bounds check!" and "you should have removed that goto line while you were working on that code!" only shows a gross lack of understanding of what real-world programming is like. It's easy to forget a simple bounds check; hell, it's a miracle a programmer gets anything done at all with all of the variables and structs and malloc() calls and pointers that have to be memorized. I recently wrote the code for adding undo support for BusyBox vi, and I can tell you firsthand that what seems like a simple thing (store changes, undo them) is a complicated and frustrating process once you start in on it. Even after I made simple undo actions work, the challenges compounded when I added the "intermediate queuing" enhancement to lower the otherwise insane malloc() overhead and improve the overall behavior of my "simplest thing that could possibly work" code.
The process of dissolving a big problem into low-level steps as is required by C programming is mentally brutal. You can't just go "I want to save the text that was deleted and restore it when they hit the undo key." You have to translate that into variables, pointers, structs, mallocs, and glue logic. You have to take into account every corner case; how do you undo multiple lines of pasted text instead of single characters? How do you store undo information a paste-over operation, where you must keep a record of what was deleted but also record that it overwrites a (possibly different length) chunk of the text buffer? How do you store the undo data for find-and-replace operations? Now that you've managed to figure out ways to store all these different types of text editing operations for undoing, how do you actually undo each one? Where does all this stuff need to hook into the existing program, and how will you hook it in without breaking existing functionality?
It's so easy to forget trivially simple things when you're trying to flow your mind through that complex glue logic that makes the magic happen, especially when you make a change, it appears to work, and you have no way to test for the bug you created by accidental error or omission.
GnuTLS exists. NSS (and NSPR [Netscape Portable Runtime] which is a hard dependency) used to have to be extracted from Mozilla source code to compile too. It was really ridiculous when I compiled it for the first time. GnuTLS is (A) not OpenSSL and (B) doesn't require NSPR. There are also OpenSSL drop-in replacements that work well, such as CyaSSL.
Programmers make these kinds of mistakes all the time. It's not uncommon. The problem is that a mistake in a text editor "undo" function is nowhere near as big of a security issue as such a mistake in a network-connected cryptography library.
Look at the recent Apple security hole: all they did was leave in a redundant "goto" statement that unfortunately had the effect of negating the purpose of the previous check and opening a hole. It could have been as simple as not deleting the line due to a distraction somewhere else in the code, and it likely passed all the unit tests (can't easily write a test for all of these types of mistakes.)
Programmers are human. They'll make a ton of mistakes. I can't say I blame him for making one; anyone who has written enough C code is used to making plenty of mistakes before something usable comes out the other end.
I appreciate what you're saying. I would like to add that diversity of viewpoints isn't necessarily achieved through diversity of skin color or gender (though there are undeniable socioeconomic forces out there that are race- and gender-heavy); viewpoints, quite literally, are all in a person's head. The value of viewpoint diversity is also dependent on what task is being performed. If someone is exclusively performing research and gathering hard data, diversity of viewpoints is of negligible value; if they're designing a product for public consumption, diversity of viewpoints is often more valuable than gold and can make or break the product.
I agree with your assessment, and I question those who would consider it sexist. Fortunately, I have observed a slow but steady correction trend in response to the constant flow of news about sexism in tech, and once naive people in tech are wising up to the games and expressing a sentiment of "sexism should be fought regardless of where it comes from, assholes are assholes whether they're men or not, and people should be free to make their choices without having to base it on their bodies." There is hope for the future.
There is no intrinsic value in someone's bodily traits that they cannot control, so "male and pale" are irrelevant factors for indoor jobs that aren't physically demanding. Adding vaginas and darker skin (or subtracting the same) has no effect to the ability to write code, create procedure analysis reports, put toothpase tubes in boxes, or use a microscope. Gender parity is flat-out irrelevant from the standpoint of hiring someone in a business to perform specific tasks.
Here's another interesting way to examine it: in "gender-dominated job" arguments, replace "male/female" with "tall/short" and see how the emotions change. Gender naturally being a binary trait only makes it lower-hanging fruit for an "us vs. them" discrimination war, but perhaps there aren't enough short people in tech either! Why aren't we seeing a "more short people in tech initiative?" People are just as likely to be discriminated against for their height as their gender.
Never mind, Wikipedia seems to have the info.
[citation needed]
So what I'm hearing is that the true problem is the bad business sense of the people controlling the jar.