October 8, 2015 at 1:49 pm
I think IoT will lead to a significant change in Computer Misuse legislation all round the world. In order to counter the viruses that will go round infecting anything they can reach, the law will need to allow similar behaviour by the good guys.
I can see licensing of 'Dettols' that would have the same dispersal processes as viruses but once in place they would kill 99% of all known germs (to quote the TV advert...). The economics of how this would be paid for would have to be sorted, but the need for Dettols will only get stronger. Without some pro-active way of getting anti-virus on to IoT devices that the legal owner has no idea how to maintain or even know it exists we will see viruses and hackers making IoT just about unusable. These bugs could be with us for decades.
The law at present prevents a Dettol from being released into the wild and treats it the same as a virus. A change is needed to allow vendors to be licensed to build and release Dettols without risk of prosecution.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
October 9, 2015 at 7:53 am
EdVassie (10/8/2015)
I think IoT will lead to a significant change in Computer Misuse legislation all round the world. In order to counter the viruses that will go round infecting anything they can reach, the law will need to allow similar behaviour by the good guys.I can see licensing of 'Dettols' that would have the same dispersal processes as viruses but once in place they would kill 99% of all known germs (to quote the TV advert...).
...
I don't follow. 'Dettol' is the brand name for an anti-bacterial soap, right?
For IoT devices, the programming should be all firmware, that should minimize opportunity for viruses and other misuse.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 9, 2015 at 7:53 am
Markus (10/8/2015)
There is a balancing act we must all in IT adhere to. Keep something running 'as is' because it just runs... versus spending a lot of money and time to upgrade. At some point old systems need to be replaced or upgraded due to the fact that the folks that have the knowledge on how to keep it running leave the company or that skillset goes away.... SQL Server 6.5.. Windows NT, code....I have been critical of Microsoft releasing new versions of SQL Server sometimes in less than 2 years of a timespan. However, the instability of older versions of operating systems and SQL Server can make upgrading a welcomed thing. SQL Server 6.5 and Windows NT were not very stable honestly. To me once we got to SQL2008R2 and Win2008 things are rock solid stable. We just got rid of our last SQL2000 dbs in May this year... took quite a long time to accomplish that. For SQL2005 I am really prodding app folks so we can have all if not almost all of our systems off of Win2003/SQL2005 by the time it goes out of extended support next Spring. I have even begun the push for upgrading some SQL2008 databases in an attempt to keep ahead of that 2019 date. With the massive amount of things in SQL2008 and 2008R2 I know we will still have stuff running those versions well into 2020.
It's definitely a balancing act. Certainly the stability of older systems can be worse, but at times we understand what's going on, so we can live with things as they are.
I like MS releasing new versions every two years. We see new features and changes quickly. There are also less changes, which means a lower learning curve, or less that might break.
We can argue about the cost/value/ROI every two years, and we have to decide if it's worth it. My only complaints are that I can't buy 2008R2 right now. I'd like to see a minimum sales time period for versions, maybe 4 years, so that we have some choice.
I also expect that most of my instances are going to last 8-10 years, so I'm not going to upgrade them and need support for some period of time.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 9, 2015 at 8:19 am
Steve Jones - SSC Editor (10/7/2015)
Alex Gay (10/7/2015)
I used to work for a hospital that had a clinical letters system written in Clipper, for an XBase file based database, that was 15-20 years old when replaced with a modern web based solution. There was a lot of resistance from the secretaries who liked the keyboard shortcuts of the old system, and feared that a new interface would slow down their work rate.Ahhh, Clipper. I made a nice living for a few years with this. Maybe I should contact them. They have some $$$$? :w00t:
Of course not, this is the NHS. All the money goes on front line staff. 😛
This explains why a system written in Clipper was still in use after 20 years.
October 9, 2015 at 11:13 am
I've been thinking about the original question, longevity of systems, and we have LOTS of examples of long-lived systems from various origins in this message thread. I know in my case when I'm designing a database system, I start at the bottom with the best database schema that I can do. I test it, I see that it does what I want and expect it to do, doing some revision as needed. THEN I start on the front end user code. Though it's never easy, I find it makes the front end much more straightforward. I'm not doing objects because the environments that I work in have much more straightforward records management requirements.
So my thought is that with a good design that you can proverbially bolt-on any front end and have a usable database. Just to send a shiver down peoples' spines since we're approaching Halloween, if you look at Cobol, you have a file sitting on storage somewhere. Multiple programs in different languages can modify that file. Ultimately that file might migrate to DB2 or some other SQL system and become part of a larger whole. You can normalize file designs regardless of whether or not they're in a relational DB and benefit systems.
We have an abstraction available that, if we have a solid data design on the bottom, that we have a tremendous variety of options that can be used to manipulate it. And that can contribute to longevity. The better normalized a design is, theoretically it should more easily be upgradable. No guarantees that the front end will move to a newer OS as easily, but I think languages have always had more fluidity for feature change than the underlying datastore. Of course there's always gotchas, like the cardinality estimator change between SQL '12 and '14. (Geez, am I channeling a shade of Celko?)
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
November 10, 2015 at 1:50 am
The industry needs to improve in making it easier to write long lasting back end systems.
I believe that this is only achievable through the limitation of facilities available to the system and the introduction of modular access to facilities. This will allow controlled updates of modules, reduced surface to attack and better abstractions to avoid obsolescence.
This is already happening to some degree with hosting in containers such as Docker.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 8:14 am
Maybe. I'm not sure Docker is that much better in terms of modularity, except that if it encourages smaller containers and micro-service-like architectures, that's good.
However if you end up with dependencies that prevent upgrades, which is possible with containers that host larger systems, or you have DB dependencies, then I'm not sure we're more modular.
Overall, I think we need to teach more about messaging and decoupling than we do some platform.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 10, 2015 at 9:09 am
Steve Jones - SSC Editor (11/10/2015)
...Overall, I think we need to teach more about messaging and decoupling than we do some platform.
Yes but we need the combination of knowledge, skills, and tools.
Docker is not a solution but I highlighted it as it is illustrative of the movement in the "right" direction.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 11:51 am
I do agree it's potentially a good move, but really the other things you highlighted, skills, understanding, are more important.
I can use separation of versions in VMs just as well as Docker. Certainly Docker has a lighter footprint, but without the knowledge, it won't be used well.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 2, 2019 at 2:40 pm
I do like computers on my cars, but only ECUs they shall be.
If I had the choice between an in which way ever hydraulically actuated (wether it's air or oil does not make much of a difference) sequential gearbox or an solid state (or for the Newcomers: your DCT gearbox is mechanically an "extended" sequential, too) one, I'd happily take the latter one.
I will not be able to service either gearbox and the more reliable (and faster, too) is the solid state actuated box so I would go for that one. Ofcourse I prefer a manual box but a certain amount of power available at the wheels means most average Joe's will break it to large extents.
This has happened in the past a lot when manual gearboxes were still commonly available on 500+ BHP cars. So if a manual is not available, don't go for the old horse, take the solid state one instead - if you have a choice.
It's always easy to judge things you've never known about (or don't care because it's your point, right?), so IoT is as much wizardry as are modern cars, either you care to be on top of technology and actually learn about it or rely on your old knowledge and doom everything new.
Even tho I don't live in an area affected by earthquakes I would love to have some IoT Sensors around to warn me about it. Same way I like IoT so you can as a farmer just apply the right amount of fertilizer to your crop fields instead of going by some old sworn rule to make sure enough fertilizer ends up in your drinking water. Those mentioned IoT Devices will not prevent anything but monitor Environments so someone else can make better decisions.
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply