The rebuilding process shouldn't be that long. Especially if most of the modules are (mostly) precompiled. But with the random order that things will be re-compiled, will a bad order effect the overall performance of the system?
Wouldn't the 'performance' just be an issue during boot time, or upgrade time? In other words, I'd expect slower reboots. Which then brings to question the usage. If it's being used in an always-on router, doesn't sound like a big deal. If it's on a laptop that one reboots frequently, I'd think it would
What exactly is the scope of 'support' i.e. why would a router need to be updated forever? All it has to do is pass or drop packets, and follow routing algorithms while managing internet traffic. The former can be managed w/ Whitelists, which I suggested in the above post could be user configurable to include just the sites s/he visits. So for the latter, are there changes frequently happening to routing protocols like OSFP, or EIGRP or others that change from distro to distro? And if yes, what does that affect - their performance? Like if the routing protocol weren't updated, would it actually slow down a router?
Router distros should have whitelists of the websites they wanna allow. When one configures them, one should have the capability of adding sites that ain't already there. That saves one from the default allow all, and allows one to drop all but whitelisted sites.
That changes things quite a bit, since the impression one was left w/ was that you don't have your own car, and get friends to do what one would generally do w/ either a taxi, or a 'ride-sharing' app. Yeah, yeah, I know Uber, Lyft et al are taxi services masquerading as 'ride-sharing', but that didn't explicitly look like the original point you were trying to make
Considering the fact that there are girls from the 'travel banned' countries in question, I agree w/ you more than you think. In other words, if we can have nerdy girls from Somalia or Sudan or Yemen or Libya, I don't see how Afghanistan makes a difference.
That may be something Microsoft wants, but it has about as much market presence as Windows NT on RISC did, back in the day. They have this stupid 'one size fits all' meme that has not gone away w/ Ballmer, and it shows. They tried it b/w their PCs & phones, and damaged both. Now they want IoT devices to run w/ their stuff, after they've discontinued their phone line (instead of leaving it w/ Nokia in the first place).
One good platform for an IoT would have been Windows 8 RT w/ Metro, but w/o the desktop. That is something that ATMs, for instance, could have used. Strip out any backward compatibility code for software (not drivers), but leave everything else in.
How? By not using monolithic kernels that support every device in creation, and stripping the kernel down to what is installed on the system -- especially with things like IOT devices. If it isn't installed, it doesn't need patched, it can't break, and it can't be exploited.
Huh? Linux is a monolithic kernel, and Linus is emphatically opposed to it being anything else. If any IoT vendor wants to use a microkernel based OS, they should look at Minix instead.
Router makers should use well known router distros of Linux or BSD, such as DD-WRT, OpenWRT or pFsense, instead of spinning their own. And let those organizations remote-manage them in exchange for a deal.
I prefer this story to the political or climate stories that he posts. Had some good moments in the Intel IoT thread earlier, but of late, too many/. stories are about politics or climate (which in itself is a route towards bashing Republicans)
Usually, the distros in question are either the vendor ones that come in the routers. Do the vendors add anything specific to the router software that makes it insecure? From what I understand, the reason is usually that most people are too tech-phobic to change the admin password of the router from 'admin' or 'password' to something else that they fear they'll forget.
I do the same, but for long drives, I do consider the alternatives, like public transport. Don't want to hit my warranty mileage of 70,000 miles before 7 years. Nor am I that interested in rapid depreciation of my car.
So your friends/relatives have no problems w/ driving you to wherever you wanna go, in return for... what, exactly? They may not be the asshole, but someone else is!
That said, travel ban or no travel ban, there is a good reason to put the skids on this. While the courts may have played all sorts of games w/ the DHS, one way the Administration can seal it is quietly close down the visa sections of all embassies in Muslim countries, thereby achieving the ban. This may be a thorny issue, but it was people of Afghan ethnicity and Islam who did both the Orlando nightclub shooting, as well as the dumpster attacks in New York & New Jersey. While the Afghan roboticist may indeed be just an engineer & nothing more, there is no reason to risk finding out otherwise. Yeah, it's a pity that roboticists from the banned countries are in the US, but that's due to the courts playing footsie w/ US lives.
Ain't the Core line of products way overkill for embedded? All one should need are 32-bits, and that would have a whole host of legacy software available for it
FPGAs - didn't they acquire Altera? Looks like that's something that Intel's Custom Semiconductor division could readily use (if it doesn't already) for any design requests they get from semiconductor houses, and run a business on that based on volumes.
On CPUs, Intel never succeeded w/ any of their non-x86 attempts, which was a pity. i960 went into embedded, i860 was used in some supercomputers, Itanium, we all know, XScale ultimately got sold,... I happen to think that instead of the IoT market, Intel should try to become a fab for Apple & Qualcomm in addition to their own PC chips, so that they can have a more diverse coverage of the market
But at the process nodes that Intel is at today, couldn't Intel easily build an entire legacy 386SX based legacy computer on one of their Altera chips for less than the cost of an ARM board?
8GB minimum for an embedded system? What exactly are you making? Here I thought that we were talking about things that need to be cheap enough to do things like a remote garage door opener, but also enough processing capabilities to support Bluetooth and accept requests from our phones & tablets. Which would suggest having a 32-bit device, but certainly not a 64-bit one.
The123king was not wrong. At current process nodes, Intel could start by taking either a 386 or 486 (they did experiments w/ the 80376 and 80386EX), putting it on one of their Altera FPGAs, putting the ISA or EISA bus on them, in fact, putting an entire legacy early 90s PC on it, w/ adequate RAM & flash, and there would be a load of software that would support it. All the early versions of Windows, FreeDOS, QNX, Minuet, Minix - platforms that for all practical purposes only exist on x86 but not really on ARM.
It doesn't have to be hotter - if the frequency of one of these systems is set at, say, 33MHz or even 8MHz, which was the speed of the ISA bus, then it would run pretty cool. One thing they could do - try providing more IRQs so that that does not remain a major hurdle the way it was 20 years ago. Back in the day, systems only had something like 4MiB of RAM or 16kiB of cache, but that is due to where process technology was then: in today's systems, one could use it up to 1GB of memory w/o hitting the barrier from 32-bit to 64-bit. In fact, you could fit in some of the OSs listed in the BIOS flash itself, and have a main storage flash for all the data, downloadable programs, et al. More crudely expressed, make the BIOS + OS drive your C:\ and your data + downloadable programs your D:\ drive. Point is you could have a complete ASIC in a TQFP package that would consume minimal real estate on a PCB, while providing everything the system needs. Only thing - I doubt one could retrofit things like an SD card or a WiFi on such a system, even externally on board.
The 386SX? If they just took that design, added some level 1 cache and put it on their current most inexpensive process, they'd be optimal for it.
That would be extremely over-complex.
x86 ISA isn't exactly a lean architecture and instruction set.
Modern ARM can do much better with a small transistor foot print.
But too bad, Intel discontinued their StrongARM serie.
Actually, that chip was rebranded as Xscale, and sold to Marvel 10 years ago. It's not that Intel didn't try working w/ it.
Why wouldn't a 386 be much of a selling point, when every embedded OS out there - not just Linux or BSD, but also things like FreeDOS, QNX, Minix, Minuet, et al exists for that platform.
The main selling point of a x86 chip would be code compatibility.
But nobody sane in their mind is going to try to run Windows XP on a IoT device.
All the other OSes are also available on ARM.
The other point where x86 shines is raw performance on high range CPUs (simply because Intel and AMD [x86] are the only company spending R&D money on optimizing chips for that segment. Everybody else - Apple, Qualcom, etc. - are optimizing for the embed market)
but that's absolutely NOT what's needed on IoT devices.
Uh, no. QNX is x86 only, IIRC (unless RIM ported it for Blackberry), and Minuet is written specifically in x86 assembly, so that it could create the most compact code. While Minix is FOSS, it has only been/is being ported to the Beaglebone: if you wanna run it on a Raspberry or an Arduino, good luck!
I also wouldn't call the tablet & phone markets 'embedded' - they are more of wireless consumer goods. Different segments from electronics that are embedded for all sorts of process control, be it home climate controls and so on. Also, does Apple sell the A series chipset at all - I thought they just use it for internal consumption. Qualcomm has as captive a market as Intel did in PCs - any phonemaker who wants to support not just current 4G & 3G but also legacy architectures like CDMA would have no alternative to Qualcomm, since Intel isn't licensed to include legacy compatibility on their chipsets
But if you're doing the 386, there IS legacy software. While the latest Linux kernels may have dropped 386 support, it still has a bunch of legacy OSs that anyone can dig up.
What is the oldest/largest process Intel currently runs - which they haven't retooled to newer shrinks? They could use that as the platform for their embedded products, and then build an SoC w/ the 386SX, 1MB of level 1 cache, 2GB of embedded RAM, 1MB of BIOS flash, built on the old 386SX package. Then such a system could support anything from a Minix setup to a Windows XP configuration used in ATMs.
Slashdot Mirror
The rebuilding process shouldn't be that long. Especially if most of the modules are (mostly) precompiled. But with the random order that things will be re-compiled, will a bad order effect the overall performance of the system?
Wouldn't the 'performance' just be an issue during boot time, or upgrade time? In other words, I'd expect slower reboots. Which then brings to question the usage. If it's being used in an always-on router, doesn't sound like a big deal. If it's on a laptop that one reboots frequently, I'd think it would
What exactly is the scope of 'support' i.e. why would a router need to be updated forever? All it has to do is pass or drop packets, and follow routing algorithms while managing internet traffic. The former can be managed w/ Whitelists, which I suggested in the above post could be user configurable to include just the sites s/he visits. So for the latter, are there changes frequently happening to routing protocols like OSFP, or EIGRP or others that change from distro to distro? And if yes, what does that affect - their performance? Like if the routing protocol weren't updated, would it actually slow down a router?
Router distros should have whitelists of the websites they wanna allow. When one configures them, one should have the capability of adding sites that ain't already there. That saves one from the default allow all, and allows one to drop all but whitelisted sites.
That changes things quite a bit, since the impression one was left w/ was that you don't have your own car, and get friends to do what one would generally do w/ either a taxi, or a 'ride-sharing' app. Yeah, yeah, I know Uber, Lyft et al are taxi services masquerading as 'ride-sharing', but that didn't explicitly look like the original point you were trying to make
Considering the fact that there are girls from the 'travel banned' countries in question, I agree w/ you more than you think. In other words, if we can have nerdy girls from Somalia or Sudan or Yemen or Libya, I don't see how Afghanistan makes a difference.
That may be something Microsoft wants, but it has about as much market presence as Windows NT on RISC did, back in the day. They have this stupid 'one size fits all' meme that has not gone away w/ Ballmer, and it shows. They tried it b/w their PCs & phones, and damaged both. Now they want IoT devices to run w/ their stuff, after they've discontinued their phone line (instead of leaving it w/ Nokia in the first place).
One good platform for an IoT would have been Windows 8 RT w/ Metro, but w/o the desktop. That is something that ATMs, for instance, could have used. Strip out any backward compatibility code for software (not drivers), but leave everything else in.
How? By not using monolithic kernels that support every device in creation, and stripping the kernel down to what is installed on the system -- especially with things like IOT devices. If it isn't installed, it doesn't need patched, it can't break, and it can't be exploited.
Huh? Linux is a monolithic kernel, and Linus is emphatically opposed to it being anything else. If any IoT vendor wants to use a microkernel based OS, they should look at Minix instead.
Router makers should use well known router distros of Linux or BSD, such as DD-WRT, OpenWRT or pFsense, instead of spinning their own. And let those organizations remote-manage them in exchange for a deal.
I prefer this story to the political or climate stories that he posts. Had some good moments in the Intel IoT thread earlier, but of late, too many /. stories are about politics or climate (which in itself is a route towards bashing Republicans)
Usually, the distros in question are either the vendor ones that come in the routers. Do the vendors add anything specific to the router software that makes it insecure? From what I understand, the reason is usually that most people are too tech-phobic to change the admin password of the router from 'admin' or 'password' to something else that they fear they'll forget.
How does Open Source reveal to you whether something is stolen? The thief could well have changed the attributions & credits in the code
I'd like to see the Libertarian Party replace the Democrats, since the Republicans have moved a whole lot Left than where they were back in the day
I do the same, but for long drives, I do consider the alternatives, like public transport. Don't want to hit my warranty mileage of 70,000 miles before 7 years. Nor am I that interested in rapid depreciation of my car.
So Curb?
Your comment should be addressed to mentil, not Nkwe
So your friends/relatives have no problems w/ driving you to wherever you wanna go, in return for... what, exactly? They may not be the asshole, but someone else is!
This is very true
That said, travel ban or no travel ban, there is a good reason to put the skids on this. While the courts may have played all sorts of games w/ the DHS, one way the Administration can seal it is quietly close down the visa sections of all embassies in Muslim countries, thereby achieving the ban. This may be a thorny issue, but it was people of Afghan ethnicity and Islam who did both the Orlando nightclub shooting, as well as the dumpster attacks in New York & New Jersey. While the Afghan roboticist may indeed be just an engineer & nothing more, there is no reason to risk finding out otherwise. Yeah, it's a pity that roboticists from the banned countries are in the US, but that's due to the courts playing footsie w/ US lives.
Ain't the Core line of products way overkill for embedded? All one should need are 32-bits, and that would have a whole host of legacy software available for it
FPGAs - didn't they acquire Altera? Looks like that's something that Intel's Custom Semiconductor division could readily use (if it doesn't already) for any design requests they get from semiconductor houses, and run a business on that based on volumes.
On CPUs, Intel never succeeded w/ any of their non-x86 attempts, which was a pity. i960 went into embedded, i860 was used in some supercomputers, Itanium, we all know, XScale ultimately got sold,... I happen to think that instead of the IoT market, Intel should try to become a fab for Apple & Qualcomm in addition to their own PC chips, so that they can have a more diverse coverage of the market
But at the process nodes that Intel is at today, couldn't Intel easily build an entire legacy 386SX based legacy computer on one of their Altera chips for less than the cost of an ARM board?
8GB minimum for an embedded system? What exactly are you making? Here I thought that we were talking about things that need to be cheap enough to do things like a remote garage door opener, but also enough processing capabilities to support Bluetooth and accept requests from our phones & tablets. Which would suggest having a 32-bit device, but certainly not a 64-bit one.
The123king was not wrong. At current process nodes, Intel could start by taking either a 386 or 486 (they did experiments w/ the 80376 and 80386EX), putting it on one of their Altera FPGAs, putting the ISA or EISA bus on them, in fact, putting an entire legacy early 90s PC on it, w/ adequate RAM & flash, and there would be a load of software that would support it. All the early versions of Windows, FreeDOS, QNX, Minuet, Minix - platforms that for all practical purposes only exist on x86 but not really on ARM.
It doesn't have to be hotter - if the frequency of one of these systems is set at, say, 33MHz or even 8MHz, which was the speed of the ISA bus, then it would run pretty cool. One thing they could do - try providing more IRQs so that that does not remain a major hurdle the way it was 20 years ago. Back in the day, systems only had something like 4MiB of RAM or 16kiB of cache, but that is due to where process technology was then: in today's systems, one could use it up to 1GB of memory w/o hitting the barrier from 32-bit to 64-bit. In fact, you could fit in some of the OSs listed in the BIOS flash itself, and have a main storage flash for all the data, downloadable programs, et al. More crudely expressed, make the BIOS + OS drive your C:\ and your data + downloadable programs your D:\ drive. Point is you could have a complete ASIC in a TQFP package that would consume minimal real estate on a PCB, while providing everything the system needs. Only thing - I doubt one could retrofit things like an SD card or a WiFi on such a system, even externally on board.
Do they need the latest & greatest kernel release to work? Can't they just pick whichever the last version of the 32-bit kernel was, and work w/ that?
The 386SX? If they just took that design, added some level 1 cache and put it on their current most inexpensive process, they'd be optimal for it.
That would be extremely over-complex. x86 ISA isn't exactly a lean architecture and instruction set. Modern ARM can do much better with a small transistor foot print.
But too bad, Intel discontinued their StrongARM serie.
Actually, that chip was rebranded as Xscale, and sold to Marvel 10 years ago. It's not that Intel didn't try working w/ it.
Why wouldn't a 386 be much of a selling point, when every embedded OS out there - not just Linux or BSD, but also things like FreeDOS, QNX, Minix, Minuet, et al exists for that platform.
The main selling point of a x86 chip would be code compatibility. But nobody sane in their mind is going to try to run Windows XP on a IoT device. All the other OSes are also available on ARM.
The other point where x86 shines is raw performance on high range CPUs (simply because Intel and AMD [x86] are the only company spending R&D money on optimizing chips for that segment. Everybody else - Apple, Qualcom, etc. - are optimizing for the embed market) but that's absolutely NOT what's needed on IoT devices.
Uh, no. QNX is x86 only, IIRC (unless RIM ported it for Blackberry), and Minuet is written specifically in x86 assembly, so that it could create the most compact code. While Minix is FOSS, it has only been/is being ported to the Beaglebone: if you wanna run it on a Raspberry or an Arduino, good luck!
I also wouldn't call the tablet & phone markets 'embedded' - they are more of wireless consumer goods. Different segments from electronics that are embedded for all sorts of process control, be it home climate controls and so on. Also, does Apple sell the A series chipset at all - I thought they just use it for internal consumption. Qualcomm has as captive a market as Intel did in PCs - any phonemaker who wants to support not just current 4G & 3G but also legacy architectures like CDMA would have no alternative to Qualcomm, since Intel isn't licensed to include legacy compatibility on their chipsets
But if you're doing the 386, there IS legacy software. While the latest Linux kernels may have dropped 386 support, it still has a bunch of legacy OSs that anyone can dig up.
In Vietnam?
What is the oldest/largest process Intel currently runs - which they haven't retooled to newer shrinks? They could use that as the platform for their embedded products, and then build an SoC w/ the 386SX, 1MB of level 1 cache, 2GB of embedded RAM, 1MB of BIOS flash, built on the old 386SX package. Then such a system could support anything from a Minix setup to a Windows XP configuration used in ATMs.