Let's see, the tiny amount of L1/2/3 cache currently is dictated by the energy budget of the CPU. Looking at the energy budget of the 4900MQ and the 4960HQ chips, you can take some wild arse guessing to get that the 2 megs of L3 cache sacrificed got back enough to power the 128 megs of L4. Then consider that there is only 64K (yes, kilobytes) of L1 or 256K L2 per core on the Haswell chips, and at 3.9GHz desktop chips you are looking at 84 watts of power dissipated . . . you can start to work out how much of that is due to leakage current from the 6 transistor L1/2/3 cache design.
Let's face it, SRAM isn't tiny, it leaks amps like a sieve at the tiny process size that everything is done at now days, and it's main advantage is that it doesn't take a controller to access and it's bloody fast and the bandwidth can be pretty sizable. A gig of SRAM on die would, I suspect, heat a small room; that much DRAM per core would slow the cores down due to the inherent latency of accessing DRAM.
So, sure, DRAM chips may be cheap, but putting them on the CPU die would be horrid. And SRAM still isn't cheap; either in die space, energy budget, or dollars!
If you are writing the OS and your code is down at the machine level, you do know what's going on in the different cache pools. You can abstract it away and trust your compiler to get it right, or you can fiddle the bits yourself; it isn't magic contained in the blue smoke of ICs.
Photoshop? Considering that the adobe rgb or other color spaces combined with the file sizes of some of the larger images coming out of cameras, your gains in latency would really depend on Photoshop and the OS being able to handle the L4 cache and keep the right part of the image in the cache. Video editing, with file sizes into the gigabyte range would probably see no gains at all. Video conversion, with a program that keeps a reasonably sized buffer, should see a good performance gain; but it would require code that knows the L4 is available or the OS to predict that L4 is a good place to put a 10-50-100MB buffer. The real gain will be in common things: playing a video, browsing the web (seen how much memory a bit of javascript or the JRE can eat up lately? Or Silverlight/Flash?) and email clients (cache all your email in L4 for faster searching).
As for battery life, I have no idea. It might use more power, since DRAM requires constant power to refresh data where SRAM is pretty stable; but the lower leakage of using a single transistor instead of 6 might prove to be a benefit. It would take a good bit of time and some pretty good test code to figure the difference, I suspect.
And yet if you are sitting on a jury in a trial, they can and have made laws requiring you not to talk about what you've learned til after the trial. Is that not also a law abridging freedom of speech? Gag orders on the press covering a trial also exist; same question.
With the number of counter-top vacuum preserver devices, doing sous vide in home is not that hard. It's not as perfect as a full industrial vacu-sealer, but it works. Additionally, LN isn't too hard to get in small amounts as an engineer; and for in-house use you could use dry ice or LCO2 from a fire extinguisher.
But I'm one of those home cooks who likes trying crazy chemistry shit, and has the gear and respect for the chemicals to do it safely. Might have gone to the cooking industry if I had gotten into cooking sooner. So the big set of books is still something I want, but couldn't justify the $500 for. Bet they'd look pretty in PDF format, even if the pictures were lower resolution.
Unless a userland process has a ton of OS level locks on the I/O devices (disk read/writes, managing it's own cache in files, other strange behavior) that all result in OS API calls. If the userland process does all of that, than the OS is going to grind along trying to manage all of the coder's stupidity.
Which probably explains both Adobe and the early JREs, in fact.
And it's a function that is in every graphics library, textbook, and so on. The goal is to not copy code (copyright infringement). The math for finding a normal isn't in and of itself copyrighted, though.
Posting from my phone is an awful way to try and teach about the legal side of reverse engineering code, or re-licensing, or any other legal topic. It can be, and is, done. It is one of the arguments made when talking about copyrights on algorithm. Hit google, find some articles about it, look for things like math formula copyrights and similar, and clean room reverse engineering. There are lots of articles and explanations out there.
Not at all, in fact I recall the usenet discussions regarding how to avoid just copying code. It was just a fact that they wanted to re-license under a floss license, and they wanted to migrate the code; so both were done at the same time. Some functions, it is as easy as "chinese room" coding, one person reads the old code and writes a plain English description of what it does: casts a ray along vector V, or finds normal of surface S. Another person who doesn't look at the old code writes these new functions. Considering how long the POV-Ray team have kept lawyers around, they made sure to do it right. And more recent additions, like SSLT, were written under duel license; one for the old codecode, and one giving the team permission to open it under another license.
As a disclaimer, I was lurking in their developers group on Usenet at the time (trying to contribute til life got in the way). So I got to see the hoops they jumped through to keep it clean. Lots of work contacting old devs, finding out who was legally responsible for what code and who could change the license. I think thethe archive is still readable, makes very interesting legal reading on how to reverse engineer code without breaking EULAs or licenses.
The problem with the old license was that the code was "opened" before the GPL was around. POV-Ray team came up with a license and spent years porting from Amiga to Linux to Windows to OSX under that license. Some, many in fact, of the original code contributors could not be found to allow the current team to just relicense the code. Since a rewrite to C++ was occurring at the same time, that gave the opportunity to rewrite what could not be relicensed.
I would counter balance that book with one on listening, the other half (and much neglected part) of communication. Unfortunately I can’t think of any off the top of my head. Susan Cain put out a excellent book called “Quite”. It’s not quite on point for this topic but it may be worth a read.
Let me second that, since I don't have mod points right now. Communication isn't real communication if you only ask others when you have a problem or they are your boss telling you what needs to be done. The internships I did while in Uni, I had two that were of the later form, where I'd talk to a professor, then go write the code they wanted and turned it over and moved on to what ever else they needed. No collaboration, no meaningful communication. Those projects, from my coding perspective, turned to crap and I felt like I did very little in the scheme of things. On a different project, the Ph.D I was working for wouldn't accept that; she didn't know enough about code to just hand it all over to me to do as I wished, but she also wanted to understand what I was doing in software and get my feedback on the human interface side of the project (HCI isn't my specialty at all). 90% of my brainstorming and notes and test code were done at home (still billed, of course), but I was generally only allowed to write the final code when we were both in a lab working on the project. Traded notes on the artwork, debated the file formats that would work, maximum polygon counts, and so on. We also BSed about music, books, movies, whatever. It didn't cut into the workflow, because we both understood that once a brainstorm hit you either worked it out or forgot about it; but between intense bursts of coding we just chatted while we brainstormed. End of the day, we'd trade notes and comment some more on anything that jumped out. Beat a lot of roadblocks that way, like finding the polygon limit, acceptable file formats for models in the engine I was using ("what do you mean, I have to export? Can't the engine just us a Maya file? Can't you make it use the Maya file?") instead of banging up against those walls much later and having to do some last minute kludge to jam an incompatible file type into a graphics engine. If we had waited, I would have just gotten finished files in an email, and had no way to install Maya and convert the files to something usable, and would have been forced to learn a file format and code a parser for it. Instead, she just told Maya to use a format we could agree on. Days of work that would have been past deadline, averted.
The other projects, no one asked for my notes on. I was halfway done implementing a user editable AI, where each creature would load it's own script from a master AI class that just handled object creation and destruction. Since I kept getting sidetracked to other parts of that project, by the time my days there were up, there was only a skeleton of this AI with some notes on how each part connected. The next intern or grad student probably scrapped it and started over. The tools didn't have a good place for my notes, and even when I offered copies of the notes and diagrams they weren't taken; so no loss to me.
And that's why just sitting and BSing about music or books or movies or whatever while working can result in better code. You have to listen when a colleague brings up a minor concern, or just a stray thought, and see if that applies to something that you are working on. And if it is, then you can take some time to work out what looks like a small detail ("No, I don't think you could create a model that was too high poly count. Maya should limit you....wait, you are using over a million for just the eye? wt...") that may be a bigger problem than anyone thinks. But if you skip the small talk and don't listen to the minor concerns that aren't really your area of expertise, you may miss the clue to the issues that you'll be forced into dealing with later.
Locally, sure. Heck, dropping a UI in front of the scripts that the article was asking about might make the management of the variety of devices easier; Just toss together a python program, or other easy language at hand, with the ability to call bash scrips and the ability to throw up a UI and mess with the database that tracks all the devices and their login details; that would make their scripts more usable should they all get fired tomorrow and the new team has access to an easier work flow. But remote access from a physically unsecured device to what are probably secured systems without rolling one-time-use passwords? I'm just a CS drop out, and I can spot some major security problems there. And yes, I see even remote access to the switches as a problem, since havok could be caused. Imagine copying credentials, then (if it's a smart switch or other smart device) using that to tunnel to the companies boarder router (I recall some Cisco hardware had the ability to go from it's terminal to the terminal of other Cisco devices it was connected to...could be a faulty memory, my CCNA and other stuff expired 10 years ago) and then telling your gateway (from the inside at this point) to ignore the IDS and firewall. Or terminal jump to the IDS/firewall or database and see what other credentials could be had. Heck, I'd demand a VPN from a secure(ish) computer before allowing access to a GUI or CLI...preferably one with an onscreen, randomized keyboard for credential input or crypto signature credentials and a one-time-password (SecurID or something like it). But a public computer with gods know what running on it? Even copying crypto signatures from a thumb drive would be dangerous if the right malware was paying attention; or the malware could just infect the thumb drive. And if BadBIOS turns out to be real and is infecting any usb storage device then that thumb drive with a signature would have to be a single use device, never allowed to touch a secure machine again. A bootable write only (cd or dvd) with a on-screen randomized keyboard, and the public cryto sig burned with it, and a OTP device might be away to use an unsecured computer. Might, I haven't thought, yet, on ways I could still get the info if said machine was in my physical possession and I had hardware logging devices; maybe just recording the screen and network feed would get close, but the OTP device would be a stumbling block. If it used a weak chain, and you used the key at predictable intervals (so I could get multiple "key @ X time") to feed into a rainbow table...tricky, but maybe, I'll have to ponder more.
And don't take my security concerns as a personal thing. I'm just brainstorming so if the article author reads these posts, they might get to thinking about further issues and why those local CLI scripts might not be so bad. Or someone else thinking about remote access might question their security protocol.
A thumb drive does not stop the hotel computer from having a key logger, unless you check the cables and boot into a secure OS. I spotted a physical one attached while traveling (New Jersey, Pennsylvania? somewhere up the east seaboard between Boston and DC). Was hard trying to stop my family from making a hotel reservation over a hotel's computer (that one was booked, trying to reserve a room 50 miles down the road) without screaming "because the computer is bloody compromised and that little box could be catching your credit card number!". Pity the hotel didn't care, and I was, by that point, too exhausted to care either. For all I know, it's still there.
So, wait, you replace SSH on a known secured computer (at least I hope an admin's travel computer is relatively secured) with a web UI? So you can use it from a adware, spyware filled device like a hotel lobby computer or grandma's cell phone filled with spying, keylogging games? Sure, the web UI might be over HTTPS, but that does nothing about spyware seeing you punch in the URL, then type in your username and password. I really hope your IDS knows when you are traveling, and will use the website, and when you are in the office.
I'm required by my hat to ask which hotel you are planning to stay at next, so I can get to the lobby computer a day ahead. Though the last time I spotted a USB keylogger and pointed it out to the hotel staff, they just looked at me cross-eyed and wondered why it mattered.
They could have been older and just didn't use browser bookmarks. I tended to remember site names, because the few that I needed on a regular basis were easy to remember. If it was hard to remember, I wrote it down because jumping between different browsers and surviving updates to netscape was tough. Or remember the chain of links of how I got there.
Though I feel like a young'in on the internet when I hear people reminiscing about gopher
Oh gods, I know people with security clearance who could probably get either of those to the ears or desks of someone likely to fall for it. It's rare that such a simple idea that's so hard to understand (geosync orbits) can be sold as both a failure of and to deregulate. And the temptation to troll the entire government is so very tempting.
The windows release of LMMS is a bit buggy and finicky, but once I installed it in Ubuntu Studio (I could go source-only route, but letting someone else manage the package dependencies is easier, k?) it ran very well. With JACK handling the low latency interconnects between the usb midi adapter and the soft synth, and from the soft synth into LMMS, or from a simple app with some ALSA out to a software effects rack (Ubuntu Studio comes with a few) with JACK connecting that to LMMS, it all just seems to work. JACK is the glue that ends up tying all the pieces together, but if you are a Linux audio geek you either know that or are going to get very familiar with it very quickly. The other two I have very little personal experience with, but they are other big name DAW in the Linux world that I have yet to see mentioned.
I don't doubt that needing a MAC makes it a layer 2 device. I was arguing that if it had a MAC, that is probably capable of being connected to and is more than likely a layer 3 device. A modem can act just fine as a portal between Ethernet and SomethingElse without existing at layer 2. The Ethernet device only sees the MAC and IP of the router/other device beyond the modem, and sends a packet out the Uplink port. You even mention a network bridge which were, in Ethernet cases anyways, invisible layer 1 devices with no MAC, that were just signal amplifiers. As for DSL spec'ed as being a layer 2 protocol, that's outside my personal realm of specialized knowledge. The behavior of a modem does not require such, since it just converts from one physical layer to another. See http://www.linfo.org/physical_layer.html and http://en.wikipedia.org/wiki/Physical_layer for where I pulled opinions to back my knowledge from old cisco classes. Now, in searching, it seems that the ADSL spec does lay out layer 2. Since ADSL has basically replaced DSL, maybe that's where our confusion lay.
There was never an intent for SSN to not be duplicated. The only guarantee was that it would not be duplicated to someone with the same name! And when the living+dead since 19xx (i forget which year SSNs were issued) crosses the billion mark, you can be guaranteed of some duplicates.
Okay, I went offline for a while so this is late. You say your router speaks PPPoE to the modem; not technically true. The PPPoE is being sent to your ISP (i hope, or your connection is really hare-brained) to verify that you have an account. The signal goes through the modem, over the phone lines, and to the ISP servers.
Now, the important thing to think about is "what is the first device in from the wall that you can access via an IP address?" If you can bring up the modem's configuration by an IP (10.x.x.x or something) than the modem is not a simple modem, but a modem+router device. It may only present that internally, but if it allows you to change it's MAC on the external side, then that's the only MAC that needs changing. If the modem is dumb, then you change the MAC on the external side of the router. If your DHCP requests are going from your computer, through the router and being answered by the ISP (not likely with a 192.168.x.x internal address, but hey, it's possible) then changing the computers MAC should get a new IP from the DHCP server; but this is a highly unlikely configuration.
Lastly, in all likelihood since you mention the router being 192.168.x.1 and I guess having a externally accessible non-NAT IP, then yes, you router is getting it's IP from your ISP when the router comes online and refreshing that every . . . it depends on your ISP how often that is. The IP is not being given by the modem UNLESS the modem is also a router with dhcp service built in; in which case it's the device you need to focus on. Vaguely similar to old SLIP lines, but they used IPCP instead of DHCP; if memory serves.
The MoDem (modulate/demodulate) is a layer 1 device. Most DSL "Modems" are also routers or switches, and then have a MAC and maybe an IP address. A rather old, dumb, DSL modem will not have those and will require a USB (or serial or jtag) connection to access it's internals.
That is painful to watch. "Um" isn't punctuation! And he spends the whole video talking about how some bad developers code very badly and don't check stuff, so please submit your code better...in a talk titled "I don't want your code". This is all kernel level stuff that, frankly, a 'joe average user' should never deal with. A stable system shouldn't be updating to every kernel RC, and either the user or the package management (utility or the folks behind the distro) are at fault here if the target is an "average user"..
Linux has had the same kernel level API for a long time. They work rather hard to not change that level at all, so that the stuff above it (shell/X/WM/OpenGL/game) doesn't have to worry about it. So, yeah, if you run a bleeding edge nightly compiled kernel and wonder why the machine crashes some days, that's your choice, not the Linux system. If you stick to stable kernels, and libraries that have stable API (or are statically linked or have explicit version requirements in the documentation and package management tool of choice) then you won't hit this problem! Ever!
As for making a OSX compatibility layer, why not convince OSX developers to use multi OS friendly libraries like SDL(Simple Directmedia Layer)? Input, graphics, audio and more, in a library that builds across all the major OSes and a few consoles! Sorry for the rather late reply, but it was mostly because I needed to point out that SDL does exist.
Won't get an argument from me about that point. I do without cable just fine. But, I can only get 2 channels (cbs and ion, PBS if I can ever keep the cat away from the VHF rabbit ears). I'm less than 35 from the broadcast towers for about 6 stations, but my line of sight hits so many hills that I'd need a highly directional antenna with a pre-amp according to the various websites that do that topology map stuff. My omni antenna or the small directional that I can put in the window (rented place, no rooftop stuff) just won't get a SNR that the amp can do anything with.
Funny thing was, here anyways, before the digital switch I could get the channels from VHF's tendency to bounce better. The channels were still noisy, but my eye's SNR tolerance is better than the one that digital decoders need; I could pick out the figures and listen to channels that now don't come in at all.
Flat land, or hills/mountains? Cause in the Appalachian mountains, 35 miles can be in range of one station in the city, and out of range of another just because of which hill they put their towers on. Can't imagine that the biggest west coast mountains would be any friendlier to TV signals.
Slashdot Mirror
Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?
Cache misses
Let's see, the tiny amount of L1/2/3 cache currently is dictated by the energy budget of the CPU. Looking at the energy budget of the 4900MQ and the 4960HQ chips, you can take some wild arse guessing to get that the 2 megs of L3 cache sacrificed got back enough to power the 128 megs of L4. Then consider that there is only 64K (yes, kilobytes) of L1 or 256K L2 per core on the Haswell chips, and at 3.9GHz desktop chips you are looking at 84 watts of power dissipated . . . you can start to work out how much of that is due to leakage current from the 6 transistor L1/2/3 cache design.
Let's face it, SRAM isn't tiny, it leaks amps like a sieve at the tiny process size that everything is done at now days, and it's main advantage is that it doesn't take a controller to access and it's bloody fast and the bandwidth can be pretty sizable. A gig of SRAM on die would, I suspect, heat a small room; that much DRAM per core would slow the cores down due to the inherent latency of accessing DRAM.
So, sure, DRAM chips may be cheap, but putting them on the CPU die would be horrid. And SRAM still isn't cheap; either in die space, energy budget, or dollars!
If you are writing the OS and your code is down at the machine level, you do know what's going on in the different cache pools. You can abstract it away and trust your compiler to get it right, or you can fiddle the bits yourself; it isn't magic contained in the blue smoke of ICs.
Photoshop? Considering that the adobe rgb or other color spaces combined with the file sizes of some of the larger images coming out of cameras, your gains in latency would really depend on Photoshop and the OS being able to handle the L4 cache and keep the right part of the image in the cache. Video editing, with file sizes into the gigabyte range would probably see no gains at all. Video conversion, with a program that keeps a reasonably sized buffer, should see a good performance gain; but it would require code that knows the L4 is available or the OS to predict that L4 is a good place to put a 10-50-100MB buffer. The real gain will be in common things: playing a video, browsing the web (seen how much memory a bit of javascript or the JRE can eat up lately? Or Silverlight/Flash?) and email clients (cache all your email in L4 for faster searching).
As for battery life, I have no idea. It might use more power, since DRAM requires constant power to refresh data where SRAM is pretty stable; but the lower leakage of using a single transistor instead of 6 might prove to be a benefit. It would take a good bit of time and some pretty good test code to figure the difference, I suspect.
And yet if you are sitting on a jury in a trial, they can and have made laws requiring you not to talk about what you've learned til after the trial. Is that not also a law abridging freedom of speech? Gag orders on the press covering a trial also exist; same question.
With the number of counter-top vacuum preserver devices, doing sous vide in home is not that hard. It's not as perfect as a full industrial vacu-sealer, but it works. Additionally, LN isn't too hard to get in small amounts as an engineer; and for in-house use you could use dry ice or LCO2 from a fire extinguisher.
But I'm one of those home cooks who likes trying crazy chemistry shit, and has the gear and respect for the chemicals to do it safely. Might have gone to the cooking industry if I had gotten into cooking sooner. So the big set of books is still something I want, but couldn't justify the $500 for. Bet they'd look pretty in PDF format, even if the pictures were lower resolution.
Unless a userland process has a ton of OS level locks on the I/O devices (disk read/writes, managing it's own cache in files, other strange behavior) that all result in OS API calls. If the userland process does all of that, than the OS is going to grind along trying to manage all of the coder's stupidity.
Which probably explains both Adobe and the early JREs, in fact.
And it's a function that is in every graphics library, textbook, and so on. The goal is to not copy code (copyright infringement). The math for finding a normal isn't in and of itself copyrighted, though.
Posting from my phone is an awful way to try and teach about the legal side of reverse engineering code, or re-licensing, or any other legal topic. It can be, and is, done. It is one of the arguments made when talking about copyrights on algorithm. Hit google, find some articles about it, look for things like math formula copyrights and similar, and clean room reverse engineering. There are lots of articles and explanations out there.
Not at all, in fact I recall the usenet discussions regarding how to avoid just copying code. It was just a fact that they wanted to re-license under a floss license, and they wanted to migrate the code; so both were done at the same time. Some functions, it is as easy as "chinese room" coding, one person reads the old code and writes a plain English description of what it does: casts a ray along vector V, or finds normal of surface S. Another person who doesn't look at the old code writes these new functions. Considering how long the POV-Ray team have kept lawyers around, they made sure to do it right. And more recent additions, like SSLT, were written under duel license; one for the old codecode, and one giving the team permission to open it under another license.
As a disclaimer, I was lurking in their developers group on Usenet at the time (trying to contribute til life got in the way). So I got to see the hoops they jumped through to keep it clean. Lots of work contacting old devs, finding out who was legally responsible for what code and who could change the license. I think thethe archive is still readable, makes very interesting legal reading on how to reverse engineer code without breaking EULAs or licenses.
The problem with the old license was that the code was "opened" before the GPL was around. POV-Ray team came up with a license and spent years porting from Amiga to Linux to Windows to OSX under that license. Some, many in fact, of the original code contributors could not be found to allow the current team to just relicense the code. Since a rewrite to C++ was occurring at the same time, that gave the opportunity to rewrite what could not be relicensed.
I would counter balance that book with one on listening, the other half (and much neglected part) of communication. Unfortunately I can’t think of any off the top of my head. Susan Cain put out a excellent book called “Quite”. It’s not quite on point for this topic but it may be worth a read.
Let me second that, since I don't have mod points right now. Communication isn't real communication if you only ask others when you have a problem or they are your boss telling you what needs to be done. The internships I did while in Uni, I had two that were of the later form, where I'd talk to a professor, then go write the code they wanted and turned it over and moved on to what ever else they needed. No collaboration, no meaningful communication. Those projects, from my coding perspective, turned to crap and I felt like I did very little in the scheme of things. On a different project, the Ph.D I was working for wouldn't accept that; she didn't know enough about code to just hand it all over to me to do as I wished, but she also wanted to understand what I was doing in software and get my feedback on the human interface side of the project (HCI isn't my specialty at all). 90% of my brainstorming and notes and test code were done at home (still billed, of course), but I was generally only allowed to write the final code when we were both in a lab working on the project. Traded notes on the artwork, debated the file formats that would work, maximum polygon counts, and so on. We also BSed about music, books, movies, whatever. It didn't cut into the workflow, because we both understood that once a brainstorm hit you either worked it out or forgot about it; but between intense bursts of coding we just chatted while we brainstormed. End of the day, we'd trade notes and comment some more on anything that jumped out. Beat a lot of roadblocks that way, like finding the polygon limit, acceptable file formats for models in the engine I was using ("what do you mean, I have to export? Can't the engine just us a Maya file? Can't you make it use the Maya file?") instead of banging up against those walls much later and having to do some last minute kludge to jam an incompatible file type into a graphics engine. If we had waited, I would have just gotten finished files in an email, and had no way to install Maya and convert the files to something usable, and would have been forced to learn a file format and code a parser for it. Instead, she just told Maya to use a format we could agree on. Days of work that would have been past deadline, averted.
The other projects, no one asked for my notes on. I was halfway done implementing a user editable AI, where each creature would load it's own script from a master AI class that just handled object creation and destruction. Since I kept getting sidetracked to other parts of that project, by the time my days there were up, there was only a skeleton of this AI with some notes on how each part connected. The next intern or grad student probably scrapped it and started over. The tools didn't have a good place for my notes, and even when I offered copies of the notes and diagrams they weren't taken; so no loss to me.
And that's why just sitting and BSing about music or books or movies or whatever while working can result in better code. You have to listen when a colleague brings up a minor concern, or just a stray thought, and see if that applies to something that you are working on. And if it is, then you can take some time to work out what looks like a small detail ("No, I don't think you could create a model that was too high poly count. Maya should limit you....wait, you are using over a million for just the eye? wt...") that may be a bigger problem than anyone thinks. But if you skip the small talk and don't listen to the minor concerns that aren't really your area of expertise, you may miss the clue to the issues that you'll be forced into dealing with later.
Locally, sure. Heck, dropping a UI in front of the scripts that the article was asking about might make the management of the variety of devices easier; Just toss together a python program, or other easy language at hand, with the ability to call bash scrips and the ability to throw up a UI and mess with the database that tracks all the devices and their login details; that would make their scripts more usable should they all get fired tomorrow and the new team has access to an easier work flow.
But remote access from a physically unsecured device to what are probably secured systems without rolling one-time-use passwords? I'm just a CS drop out, and I can spot some major security problems there. And yes, I see even remote access to the switches as a problem, since havok could be caused. Imagine copying credentials, then (if it's a smart switch or other smart device) using that to tunnel to the companies boarder router (I recall some Cisco hardware had the ability to go from it's terminal to the terminal of other Cisco devices it was connected to...could be a faulty memory, my CCNA and other stuff expired 10 years ago) and then telling your gateway (from the inside at this point) to ignore the IDS and firewall. Or terminal jump to the IDS/firewall or database and see what other credentials could be had. Heck, I'd demand a VPN from a secure(ish) computer before allowing access to a GUI or CLI...preferably one with an onscreen, randomized keyboard for credential input or crypto signature credentials and a one-time-password (SecurID or something like it). But a public computer with gods know what running on it? Even copying crypto signatures from a thumb drive would be dangerous if the right malware was paying attention; or the malware could just infect the thumb drive. And if BadBIOS turns out to be real and is infecting any usb storage device then that thumb drive with a signature would have to be a single use device, never allowed to touch a secure machine again. A bootable write only (cd or dvd) with a on-screen randomized keyboard, and the public cryto sig burned with it, and a OTP device might be away to use an unsecured computer. Might, I haven't thought, yet, on ways I could still get the info if said machine was in my physical possession and I had hardware logging devices; maybe just recording the screen and network feed would get close, but the OTP device would be a stumbling block. If it used a weak chain, and you used the key at predictable intervals (so I could get multiple "key @ X time") to feed into a rainbow table...tricky, but maybe, I'll have to ponder more.
And don't take my security concerns as a personal thing. I'm just brainstorming so if the article author reads these posts, they might get to thinking about further issues and why those local CLI scripts might not be so bad. Or someone else thinking about remote access might question their security protocol.
Be glad you skipped ConsolePro2012+++ Platinum. It was utter garbage.
A thumb drive does not stop the hotel computer from having a key logger, unless you check the cables and boot into a secure OS. I spotted a physical one attached while traveling (New Jersey, Pennsylvania? somewhere up the east seaboard between Boston and DC). Was hard trying to stop my family from making a hotel reservation over a hotel's computer (that one was booked, trying to reserve a room 50 miles down the road) without screaming "because the computer is bloody compromised and that little box could be catching your credit card number!". Pity the hotel didn't care, and I was, by that point, too exhausted to care either. For all I know, it's still there.
So, wait, you replace SSH on a known secured computer (at least I hope an admin's travel computer is relatively secured) with a web UI? So you can use it from a adware, spyware filled device like a hotel lobby computer or grandma's cell phone filled with spying, keylogging games? Sure, the web UI might be over HTTPS, but that does nothing about spyware seeing you punch in the URL, then type in your username and password. I really hope your IDS knows when you are traveling, and will use the website, and when you are in the office.
I'm required by my hat to ask which hotel you are planning to stay at next, so I can get to the lobby computer a day ahead. Though the last time I spotted a USB keylogger and pointed it out to the hotel staff, they just looked at me cross-eyed and wondered why it mattered.
They could have been older and just didn't use browser bookmarks. I tended to remember site names, because the few that I needed on a regular basis were easy to remember. If it was hard to remember, I wrote it down because jumping between different browsers and surviving updates to netscape was tough. Or remember the chain of links of how I got there.
Though I feel like a young'in on the internet when I hear people reminiscing about gopher
Oh gods, I know people with security clearance who could probably get either of those to the ears or desks of someone likely to fall for it. It's rare that such a simple idea that's so hard to understand (geosync orbits) can be sold as both a failure of and to deregulate. And the temptation to troll the entire government is so very tempting.
The windows release of LMMS is a bit buggy and finicky, but once I installed it in Ubuntu Studio (I could go source-only route, but letting someone else manage the package dependencies is easier, k?) it ran very well. With JACK handling the low latency interconnects between the usb midi adapter and the soft synth, and from the soft synth into LMMS, or from a simple app with some ALSA out to a software effects rack (Ubuntu Studio comes with a few) with JACK connecting that to LMMS, it all just seems to work. JACK is the glue that ends up tying all the pieces together, but if you are a Linux audio geek you either know that or are going to get very familiar with it very quickly. The other two I have very little personal experience with, but they are other big name DAW in the Linux world that I have yet to see mentioned.
I don't doubt that needing a MAC makes it a layer 2 device. I was arguing that if it had a MAC, that is probably capable of being connected to and is more than likely a layer 3 device. A modem can act just fine as a portal between Ethernet and SomethingElse without existing at layer 2. The Ethernet device only sees the MAC and IP of the router/other device beyond the modem, and sends a packet out the Uplink port. You even mention a network bridge which were, in Ethernet cases anyways, invisible layer 1 devices with no MAC, that were just signal amplifiers. As for DSL spec'ed as being a layer 2 protocol, that's outside my personal realm of specialized knowledge. The behavior of a modem does not require such, since it just converts from one physical layer to another. See http://www.linfo.org/physical_layer.html and http://en.wikipedia.org/wiki/Physical_layer for where I pulled opinions to back my knowledge from old cisco classes. Now, in searching, it seems that the ADSL spec does lay out layer 2. Since ADSL has basically replaced DSL, maybe that's where our confusion lay.
There was never an intent for SSN to not be duplicated. The only guarantee was that it would not be duplicated to someone with the same name! And when the living+dead since 19xx (i forget which year SSNs were issued) crosses the billion mark, you can be guaranteed of some duplicates.
Okay, I went offline for a while so this is late. You say your router speaks PPPoE to the modem; not technically true. The PPPoE is being sent to your ISP (i hope, or your connection is really hare-brained) to verify that you have an account. The signal goes through the modem, over the phone lines, and to the ISP servers.
Now, the important thing to think about is "what is the first device in from the wall that you can access via an IP address?" If you can bring up the modem's configuration by an IP (10.x.x.x or something) than the modem is not a simple modem, but a modem+router device. It may only present that internally, but if it allows you to change it's MAC on the external side, then that's the only MAC that needs changing. If the modem is dumb, then you change the MAC on the external side of the router. If your DHCP requests are going from your computer, through the router and being answered by the ISP (not likely with a 192.168.x.x internal address, but hey, it's possible) then changing the computers MAC should get a new IP from the DHCP server; but this is a highly unlikely configuration.
Lastly, in all likelihood since you mention the router being 192.168.x.1 and I guess having a externally accessible non-NAT IP, then yes, you router is getting it's IP from your ISP when the router comes online and refreshing that every . . . it depends on your ISP how often that is. The IP is not being given by the modem UNLESS the modem is also a router with dhcp service built in; in which case it's the device you need to focus on. Vaguely similar to old SLIP lines, but they used IPCP instead of DHCP; if memory serves.
The MoDem (modulate/demodulate) is a layer 1 device. Most DSL "Modems" are also routers or switches, and then have a MAC and maybe an IP address. A rather old, dumb, DSL modem will not have those and will require a USB (or serial or jtag) connection to access it's internals.
That is painful to watch. "Um" isn't punctuation! And he spends the whole video talking about how some bad developers code very badly and don't check stuff, so please submit your code better...in a talk titled "I don't want your code". This is all kernel level stuff that, frankly, a 'joe average user' should never deal with. A stable system shouldn't be updating to every kernel RC, and either the user or the package management (utility or the folks behind the distro) are at fault here if the target is an "average user"..
Linux has had the same kernel level API for a long time. They work rather hard to not change that level at all, so that the stuff above it (shell/X/WM/OpenGL/game) doesn't have to worry about it. So, yeah, if you run a bleeding edge nightly compiled kernel and wonder why the machine crashes some days, that's your choice, not the Linux system. If you stick to stable kernels, and libraries that have stable API (or are statically linked or have explicit version requirements in the documentation and package management tool of choice) then you won't hit this problem! Ever!
As for making a OSX compatibility layer, why not convince OSX developers to use multi OS friendly libraries like SDL(Simple Directmedia Layer)? Input, graphics, audio and more, in a library that builds across all the major OSes and a few consoles! Sorry for the rather late reply, but it was mostly because I needed to point out that SDL does exist.
Won't get an argument from me about that point. I do without cable just fine. But, I can only get 2 channels (cbs and ion, PBS if I can ever keep the cat away from the VHF rabbit ears). I'm less than 35 from the broadcast towers for about 6 stations, but my line of sight hits so many hills that I'd need a highly directional antenna with a pre-amp according to the various websites that do that topology map stuff. My omni antenna or the small directional that I can put in the window (rented place, no rooftop stuff) just won't get a SNR that the amp can do anything with.
Funny thing was, here anyways, before the digital switch I could get the channels from VHF's tendency to bounce better. The channels were still noisy, but my eye's SNR tolerance is better than the one that digital decoders need; I could pick out the figures and listen to channels that now don't come in at all.
Flat land, or hills/mountains? Cause in the Appalachian mountains, 35 miles can be in range of one station in the city, and out of range of another just because of which hill they put their towers on. Can't imagine that the biggest west coast mountains would be any friendlier to TV signals.