It all depends on the type of programmer you are looking to breed.
To me, it looks like we are heading in the direction of extreme compartmentalized programming. You only need to know how your code relates to the other parts of the project. You learn more and more about what your specific role as a developer is. Then you are used to duplicate that role from project to project. Understanding the detailed ins and outs of the entire system, would then be kind of a distraction. That was one of the goals behind OOP. We are not totally there right now. But unless you are blind, you can see that this is where we will be going. For the sake of "security" systems programming will become a very esoteric art, and not what we commonly refer to when we say programmer. If you look at the closed nature of most devices used today, you see that the average user is very seperated from the OS. For all intents and purposes most UIs are not much different than a webbrowser. Soon that difference will not exist. The system will present the use with a UI that connects them to a cloud stored userspace. You will have that same userspace from device to device, and will not have access to that userspace without a network connection (network based workstations basically). Your device will have a high powered GUI and the cpu crunches local JIT code like javascript or python does now. But all of that code comes from a cloud like service. So development in large, will manly take place in very high level programming environments. Essentially programmers will be basically writing scripts. There will still be people writting compiled code. But more and more we are going to see scripting as the default meaning behind porgrammer.
So to understand how to write scripts, you just need a very limited knowledge on the systax used to write in the scripting language you are using, and the commands relevant to the task you are performing. So you could walk in knowing almost nothing about programming, and write a simple GUI or task, and what you need to know most is how to access the information that provides you with the commands you need. In a more specific and complex senario, you'll need to know how to work with a database or utilized a graphics engine.
I totally agree with the article. But that is because I mean something less modern when I say programmer. I'd like to see systems where you still have the freedom to poke and peek memory. But I'd also like "user" to mean someone that can compile their system to their specific CPU in an architecture family, and administer what running services they do and do not need running in the background of their system.
So you download it and start sifting through it all to find that O.B.L. era terrorist malware, only to find advanced backdoor contagions that exploit specific vulnerabilities in only Windows 10. I see what you did there, CIA! The malware warning was a good way to give the hacker a nice laugh. One of those inside jokes.
Your right. It isn't very interesting. Just more interesting than temporary hosting, which has been around for quite some time now. There has been a ton of sites offering this service free. I even hosted a node.js site that did it.
The niche audience doesn't need a web browser that can do what netcat and socat can do. We already have netcat and socat. But we also don't need our web browser with a built in video player. If you made netcat as easy to use as in browsers videos, the niche would probably just complain about browser bloat.
I think Opera tried some interesting things like that anyway. It never took off because the average user doesn't even imagine something like it can be done, and doesn't look for it. Especially today. Everyone is used to a man in the middle, doing for you what your computer could already do without him.
I don't think it would take a whole lot of investment either. Its not new technology. Its the basics of the Internet, that have been there since Netscape (with the exception of upnp).
One thing I have noticed, is that people do not understand the difference between hosting a file somewhere and sharing it direct IP to IP. It did the same thing right? I know any lightly seasoned user knows the difference. And most people could pick out the difference right away, if they thought about it.
But as for Mozilla putting effort into a temp host site, if you're gonna do that why not do something interesting in that comparable range of not very interesting things?
Why not a built in web interface for a upnp encrypted netcat or socat. Then you could serve pages, files, and chats; from your browser to another. If they absolutely must provide a service, they could be the web facing connection helper for those who cannot figure out firewalls or are not allowed direct connections (when upnp is not applicable). Then there is 50% less wasted bandwidth. Upload the file to the actual destination the first time. Allow extensive configurations for allowing resume, close service after completion, continue service until manually terminated, etc. You could even provide a plugin for configuring a central hub. If no one has a computer that is on all of the time, it could be another simple service they offer. Groups of peers connecting, without needing to use fackbook, DC++, Retroshare, etc. Instead lets host your files for you, and just because the link isn't accessible after some time, you can imagine that the file is deleted.
Maybe not a floppy drive. But with the ZX Spectrum Next, using a Rpi Zero as a slave, maybe opus could have something to do with the Spectrum. You can play already back PCM on Spectrums with the AY chip.
I plan to buy the ZX Next. But I'm still waiting on some parts to finish my Harlequin 128k clone.
The ZX Next has some nice clock speeds. It can also run a few other systems, like the C64. Wifi, 1.5Mb ram, 256 colors per pixel, plus whatever you can do with the ram, cpu, and gpu of the Zero. Right now they have the zero managing sprites.
Anyways....
So the real problem is that the device is so locked down that the user can't install IRC. Shouldn't have bought it if you wanted any rights like that. If everyone knew better, eventually they would sell one you could install IRC on. If you are unprivileged because your employer won't allow you to install software, maybe you shouldn't be.
There is already a program or two for chatting. Why do I need it in my web browser?
The real problem is that most of us that know Javascript sucks, are not developing alternatives. And when we do, no one uses them because they don't know why Javascript sucks.
People used to avoid computers because you had to learn in order to do something useful with it.
Instead of moving people past the barrier of ignorance, we made them ignorant of what their device is doing. Then we locked them into a development cycle scam; so that they would buy new devices to replace ones that could/would likely still function great.
The examples you give are examples created on top of other examples of doing things in a way that we don't need to. But if you want your service or game to get any attention, you have to get it where the people can reach it. So you have to provide it to them in a way that will likely require Javascript.
Bad user experience, means bad consumer experience. Some of us don't want to pay for a locked in commercial playing device that refuses to function because someone decided it was time for you to buy a new one. I agree that this isn't a high quantity of the mass feeling this way. But maybe it should be.
A good but dated computer bogged down with Javascript is a horrible reason to need a new device. Especially if you are just a consumer using it for socializing and shopping. It takes very little to get a device doing that. In the days of Win98 and XP it was millions of system tray apps and unseen services convincing you that you needed a new computer. Now its Javascript.
Those of us that dislike Javascript and Webassembly are not learning fast enough that we need to establish and "USE" alternatives. But it will be like Linux was in the beginning. Only those similarly brave will understand why you just don't buy convenience.
I don't see it happening anytime soon. But even those of us that are fed up are unlikely to subject ourselves to the barren waste land of efficient computing. Most of the younger hobbyists are starting of their adventures inspired by the very technology developments that are locking this into the commercial realm. Since the Internet and computing is more valuable to us than just a tool of commerce, we should be giving more attention to forking the industry. But because there isn't a lot of money in it, it isn't likely to happen. And if it starts, it suddenly becomes a a target of the industry it forked from. Money usually wins.
Even if you limit Javascript down in scale, what it did will just be consumed by something like it. And the drive for innovation will always create insecurity in implantation. This is where the unix philosophy shines some. Do one thing and do it well. If you need some new function, only one piece of software needs to be there for that. Or we can tie a bunch together and load them all at once in one application. Then when ever we mess up a small part, the whole becomes weakened.
The first thing is getting the F.C.C. to add a new licensing test and small frequency range for extreme novice operators. The test needs to be online, since in many areas it is hard to find 2 seasoned H.A.M. operators to test you at the current novice level. But with this new restricted operators level, you would still get an operators call sign. Then the hardware needs to be inexpensively packaged, but powerful enough to traverse in hilly or tree infested areas; to reach other persons locally. But reaching a more powerful carrier station would be more helpful. Then the software for the hardware(drivers) and the applications, needs to be under a libre/opensource license. Next is getting the F.C.C. to allow encrypted transmissions in this extreme novice frequency range. Meaning allowance of the intent to obscure the transmissions contents. They could keep the part about making sure that the transmission obscuring code is available to the public.
This is aimed at the U.S.. Other countries may have greater or lessor restrictions to overcome.
I have also seen some interesting work on UHF networking. But this might be a more complex licensing issue.
A few years back people were modifying older linksys routers to operate on frequencies specific to H.A.M. operators. They managed to get some good networking in largely populated areas. But the main turn off was getting the initial license and getting through trees and hills. No one wants to have a huge antenna in their backyard.
I really think H.A.M. is a disappearing art. Getting more people involved could produce more interested persons. Many of the bars to entry have already been dropped. You used to build a radio by hand before you could get your first license. That is no longer true.
I think a key point would be that the (proposed) Extreme Novice license would need companion equipment that is certified not to break the rules of the (proposed) Extreme Novice license.
The only way I see around this is part 15. Which is really bad for distance, unless you goes with point to point transmissions. You'd need narrow focused antenna/dishes. And likely a antenna/dish for every person linked to you in a chain of communication. No very fault tolerant. Many points of failure.
Other options include extremely high audio frequencies (bad idea) and powerful transmission of focused light (lazer). Both kinda suck.
No matter what method is used, it might be best to think about getting the most out of each transmitted bit. Things like javascript and torrent are nice aims. But realistically the fidonet systems of the dial-up bbs systems would be much better. Some H.A.M. radio hardware even has built in bbs software for message relaying. Since most options for a strong network are going to be aggressively dismissed, by the powers that be; you'll likely need to focus on a system that works around intermittently connected devices. Once connected they exchange a large amount of data for everyone on the network. The more often you connect, the better service you get and provide. But those that don't connect often can still easily get any information that wasn't meant to be private. In a system like this, you can encrypt in any way you'd like. The largest issue is connecting people over long distances. That is going to be the hard part.
Good thing they can be checked since it's open source
You can also check all of the code that suddenly relies only on systemd as a init system.
If the systemd code alters the system in a way you don't like, you can fork systemd to a way that works the way you'd like.
But then you will, in most cases, need to fork all the programs that depend on systemd working the way you don't like.
Being opensource doesn't do you any good, when the design being implemented is what some people are wary of.
Have access to the code only lets you read how they are doing exactly what you do not like. Fixing it would mean designing in a different direction. Its not the same as checking to see if you you can trust the code they are writing. Its that you don't trust the direction that the code is going, as it will slowly alter the direction of everything that relies on that code. Then you won't have a choice. You'll just have to take it, or do tons of coding to work around all of the things that have altered your system by the inclusion of systemd reliance.
It is a large undertaking, and I am glad someone forked Debain to do it.
This could easily be likened to things like Systemd and Pulseaudio. Both are really great. But not if they get in the way by aiming for only a select audience use needs. There are some that just like what they already know. Some just complain because someone else did. But some changes force a direction that can't be see, as a limitation, by those that like the change. They can't see why anyone would want to do it any different. In some cases you can change some compile flags and adjust applications to your needs. In other cases, you get unwanted bloat, or you have to work around an improvement that works against your use case. Just because it makes sense to you, and gets implemented, doesn't mean that you have made it better for everyone.
Some innovations make things easier for people that are not as experienced. The end result can be narrowing the innovations of the experienced.
Expression could be used as an example here as well. Not everyone can make out what is being expressed in a philosophical discourse. If you change the language to reach a larger audience, you'll possibly lose depth and potency.
The "command line interface vs graphical user interface" is another good example. You can be fishing around clicking your way through someones idea of an intuitive graphical work flow; or pipe a few commands together that do exactly what you need. Both are different versions of simplicity. Users of either side may find the opposing alternative way annoying.
Additionally, I've noticed this being compared to the firearms debate. The idea of "only useful to kill" has come up. In that comparison I would say that the government no longer considers the firearm, you and I can get, as a threat to its capacity to govern. But at some point in history it had been established that we should have guns to protect us from our own government. I think it is pretty obvious that you and I having weapons that can protect us from our own government is a thing of the past. If you did manage to get your hands on something, you would legally be a criminal. If not immediately, as soon as the possession became a known governing insecurity. It wasn't that long ago that the "red scare" had persons persecuted as a result of their voiced personal opinions. Opinions are not firearms or remote network tools. But it could be we are looking at something very similar anyway.
Could it be that the tool is too secure? Is it better to attack on the face of the tools negative attributes, rather than say they are trying to discourage the, possibly powerful, positive attribute(s)?
Someone asked, "Why aren't the legal users of the tool using some other VPN tool?". I think the question was asked to support the idea that those users were only using the software with negative intentions.
Just a silly way to look at the whole thing and I apologize for it.
But I can't deny the simple logic, that individual security is a governing insecurity.
When we speak of security, in a political way, it means that the government isn't prevented from governing. So eventually, providing a tool that prevents awareness of activity is very similar to hacking. You are hacking the governments security.
Slashdot Mirror
It all depends on the type of programmer you are looking to breed.
To me, it looks like we are heading in the direction of extreme compartmentalized programming. You only need to know how your code relates to the other parts of the project. You learn more and more about what your specific role as a developer is. Then you are used to duplicate that role from project to project. Understanding the detailed ins and outs of the entire system, would then be kind of a distraction. That was one of the goals behind OOP. We are not totally there right now. But unless you are blind, you can see that this is where we will be going. For the sake of "security" systems programming will become a very esoteric art, and not what we commonly refer to when we say programmer. If you look at the closed nature of most devices used today, you see that the average user is very seperated from the OS. For all intents and purposes most UIs are not much different than a webbrowser. Soon that difference will not exist. The system will present the use with a UI that connects them to a cloud stored userspace. You will have that same userspace from device to device, and will not have access to that userspace without a network connection (network based workstations basically). Your device will have a high powered GUI and the cpu crunches local JIT code like javascript or python does now. But all of that code comes from a cloud like service. So development in large, will manly take place in very high level programming environments. Essentially programmers will be basically writing scripts. There will still be people writting compiled code. But more and more we are going to see scripting as the default meaning behind porgrammer.
So to understand how to write scripts, you just need a very limited knowledge on the systax used to write in the scripting language you are using, and the commands relevant to the task you are performing. So you could walk in knowing almost nothing about programming, and write a simple GUI or task, and what you need to know most is how to access the information that provides you with the commands you need. In a more specific and complex senario, you'll need to know how to work with a database or utilized a graphics engine.
I totally agree with the article. But that is because I mean something less modern when I say programmer. I'd like to see systems where you still have the freedom to poke and peek memory. But I'd also like "user" to mean someone that can compile their system to their specific CPU in an architecture family, and administer what running services they do and do not need running in the background of their system.
So you download it and start sifting through it all to find that O.B.L. era terrorist malware, only to find advanced backdoor contagions that exploit specific vulnerabilities in only Windows 10. I see what you did there, CIA! The malware warning was a good way to give the hacker a nice laugh. One of those inside jokes.
Your right. It isn't very interesting. Just more interesting than temporary hosting, which has been around for quite some time now. There has been a ton of sites offering this service free. I even hosted a node.js site that did it. The niche audience doesn't need a web browser that can do what netcat and socat can do. We already have netcat and socat. But we also don't need our web browser with a built in video player. If you made netcat as easy to use as in browsers videos, the niche would probably just complain about browser bloat. I think Opera tried some interesting things like that anyway. It never took off because the average user doesn't even imagine something like it can be done, and doesn't look for it. Especially today. Everyone is used to a man in the middle, doing for you what your computer could already do without him. I don't think it would take a whole lot of investment either. Its not new technology. Its the basics of the Internet, that have been there since Netscape (with the exception of upnp). One thing I have noticed, is that people do not understand the difference between hosting a file somewhere and sharing it direct IP to IP. It did the same thing right? I know any lightly seasoned user knows the difference. And most people could pick out the difference right away, if they thought about it. But as for Mozilla putting effort into a temp host site, if you're gonna do that why not do something interesting in that comparable range of not very interesting things?
Why not a built in web interface for a upnp encrypted netcat or socat. Then you could serve pages, files, and chats; from your browser to another. If they absolutely must provide a service, they could be the web facing connection helper for those who cannot figure out firewalls or are not allowed direct connections (when upnp is not applicable). Then there is 50% less wasted bandwidth. Upload the file to the actual destination the first time. Allow extensive configurations for allowing resume, close service after completion, continue service until manually terminated, etc. You could even provide a plugin for configuring a central hub. If no one has a computer that is on all of the time, it could be another simple service they offer. Groups of peers connecting, without needing to use fackbook, DC++, Retroshare, etc. Instead lets host your files for you, and just because the link isn't accessible after some time, you can imagine that the file is deleted.
Maybe not a floppy drive. But with the ZX Spectrum Next, using a Rpi Zero as a slave, maybe opus could have something to do with the Spectrum. You can play already back PCM on Spectrums with the AY chip. I plan to buy the ZX Next. But I'm still waiting on some parts to finish my Harlequin 128k clone. The ZX Next has some nice clock speeds. It can also run a few other systems, like the C64. Wifi, 1.5Mb ram, 256 colors per pixel, plus whatever you can do with the ram, cpu, and gpu of the Zero. Right now they have the zero managing sprites. Anyways....
So the real problem is that the device is so locked down that the user can't install IRC. Shouldn't have bought it if you wanted any rights like that. If everyone knew better, eventually they would sell one you could install IRC on. If you are unprivileged because your employer won't allow you to install software, maybe you shouldn't be.
There is already a program or two for chatting. Why do I need it in my web browser?
The real problem is that most of us that know Javascript sucks, are not developing alternatives. And when we do, no one uses them because they don't know why Javascript sucks.
People used to avoid computers because you had to learn in order to do something useful with it.
Instead of moving people past the barrier of ignorance, we made them ignorant of what their device is doing. Then we locked them into a development cycle scam; so that they would buy new devices to replace ones that could/would likely still function great.
The examples you give are examples created on top of other examples of doing things in a way that we don't need to. But if you want your service or game to get any attention, you have to get it where the people can reach it. So you have to provide it to them in a way that will likely require Javascript.
Bad user experience, means bad consumer experience. Some of us don't want to pay for a locked in commercial playing device that refuses to function because someone decided it was time for you to buy a new one. I agree that this isn't a high quantity of the mass feeling this way. But maybe it should be.
A good but dated computer bogged down with Javascript is a horrible reason to need a new device. Especially if you are just a consumer using it for socializing and shopping. It takes very little to get a device doing that. In the days of Win98 and XP it was millions of system tray apps and unseen services convincing you that you needed a new computer. Now its Javascript.
Those of us that dislike Javascript and Webassembly are not learning fast enough that we need to establish and "USE" alternatives. But it will be like Linux was in the beginning. Only those similarly brave will understand why you just don't buy convenience.
I don't see it happening anytime soon. But even those of us that are fed up are unlikely to subject ourselves to the barren waste land of efficient computing. Most of the younger hobbyists are starting of their adventures inspired by the very technology developments that are locking this into the commercial realm. Since the Internet and computing is more valuable to us than just a tool of commerce, we should be giving more attention to forking the industry. But because there isn't a lot of money in it, it isn't likely to happen. And if it starts, it suddenly becomes a a target of the industry it forked from. Money usually wins.
Even if you limit Javascript down in scale, what it did will just be consumed by something like it. And the drive for innovation will always create insecurity in implantation. This is where the unix philosophy shines some. Do one thing and do it well. If you need some new function, only one piece of software needs to be there for that. Or we can tie a bunch together and load them all at once in one application. Then when ever we mess up a small part, the whole becomes weakened.
The first thing is getting the F.C.C. to add a new licensing test and small frequency range for extreme novice operators. The test needs to be online, since in many areas it is hard to find 2 seasoned H.A.M. operators to test you at the current novice level. But with this new restricted operators level, you would still get an operators call sign. Then the hardware needs to be inexpensively packaged, but powerful enough to traverse in hilly or tree infested areas; to reach other persons locally. But reaching a more powerful carrier station would be more helpful. Then the software for the hardware(drivers) and the applications, needs to be under a libre/opensource license. Next is getting the F.C.C. to allow encrypted transmissions in this extreme novice frequency range. Meaning allowance of the intent to obscure the transmissions contents. They could keep the part about making sure that the transmission obscuring code is available to the public. This is aimed at the U.S.. Other countries may have greater or lessor restrictions to overcome. I have also seen some interesting work on UHF networking. But this might be a more complex licensing issue. A few years back people were modifying older linksys routers to operate on frequencies specific to H.A.M. operators. They managed to get some good networking in largely populated areas. But the main turn off was getting the initial license and getting through trees and hills. No one wants to have a huge antenna in their backyard. I really think H.A.M. is a disappearing art. Getting more people involved could produce more interested persons. Many of the bars to entry have already been dropped. You used to build a radio by hand before you could get your first license. That is no longer true. I think a key point would be that the (proposed) Extreme Novice license would need companion equipment that is certified not to break the rules of the (proposed) Extreme Novice license. The only way I see around this is part 15. Which is really bad for distance, unless you goes with point to point transmissions. You'd need narrow focused antenna/dishes. And likely a antenna/dish for every person linked to you in a chain of communication. No very fault tolerant. Many points of failure. Other options include extremely high audio frequencies (bad idea) and powerful transmission of focused light (lazer). Both kinda suck. No matter what method is used, it might be best to think about getting the most out of each transmitted bit. Things like javascript and torrent are nice aims. But realistically the fidonet systems of the dial-up bbs systems would be much better. Some H.A.M. radio hardware even has built in bbs software for message relaying. Since most options for a strong network are going to be aggressively dismissed, by the powers that be; you'll likely need to focus on a system that works around intermittently connected devices. Once connected they exchange a large amount of data for everyone on the network. The more often you connect, the better service you get and provide. But those that don't connect often can still easily get any information that wasn't meant to be private. In a system like this, you can encrypt in any way you'd like. The largest issue is connecting people over long distances. That is going to be the hard part.
Good thing they can be checked since it's open source
You can also check all of the code that suddenly relies only on systemd as a init system. If the systemd code alters the system in a way you don't like, you can fork systemd to a way that works the way you'd like. But then you will, in most cases, need to fork all the programs that depend on systemd working the way you don't like. Being opensource doesn't do you any good, when the design being implemented is what some people are wary of. Have access to the code only lets you read how they are doing exactly what you do not like. Fixing it would mean designing in a different direction. Its not the same as checking to see if you you can trust the code they are writing. Its that you don't trust the direction that the code is going, as it will slowly alter the direction of everything that relies on that code. Then you won't have a choice. You'll just have to take it, or do tons of coding to work around all of the things that have altered your system by the inclusion of systemd reliance. It is a large undertaking, and I am glad someone forked Debain to do it.
This could easily be likened to things like Systemd and Pulseaudio. Both are really great. But not if they get in the way by aiming for only a select audience use needs. There are some that just like what they already know. Some just complain because someone else did. But some changes force a direction that can't be see, as a limitation, by those that like the change. They can't see why anyone would want to do it any different. In some cases you can change some compile flags and adjust applications to your needs. In other cases, you get unwanted bloat, or you have to work around an improvement that works against your use case. Just because it makes sense to you, and gets implemented, doesn't mean that you have made it better for everyone. Some innovations make things easier for people that are not as experienced. The end result can be narrowing the innovations of the experienced. Expression could be used as an example here as well. Not everyone can make out what is being expressed in a philosophical discourse. If you change the language to reach a larger audience, you'll possibly lose depth and potency. The "command line interface vs graphical user interface" is another good example. You can be fishing around clicking your way through someones idea of an intuitive graphical work flow; or pipe a few commands together that do exactly what you need. Both are different versions of simplicity. Users of either side may find the opposing alternative way annoying.
Additionally, I've noticed this being compared to the firearms debate. The idea of "only useful to kill" has come up. In that comparison I would say that the government no longer considers the firearm, you and I can get, as a threat to its capacity to govern. But at some point in history it had been established that we should have guns to protect us from our own government. I think it is pretty obvious that you and I having weapons that can protect us from our own government is a thing of the past. If you did manage to get your hands on something, you would legally be a criminal. If not immediately, as soon as the possession became a known governing insecurity. It wasn't that long ago that the "red scare" had persons persecuted as a result of their voiced personal opinions. Opinions are not firearms or remote network tools. But it could be we are looking at something very similar anyway.
Could it be that the tool is too secure? Is it better to attack on the face of the tools negative attributes, rather than say they are trying to discourage the, possibly powerful, positive attribute(s)? Someone asked, "Why aren't the legal users of the tool using some other VPN tool?". I think the question was asked to support the idea that those users were only using the software with negative intentions. Just a silly way to look at the whole thing and I apologize for it. But I can't deny the simple logic, that individual security is a governing insecurity. When we speak of security, in a political way, it means that the government isn't prevented from governing. So eventually, providing a tool that prevents awareness of activity is very similar to hacking. You are hacking the governments security.