Re:support for automated offsite backup?
on
What NAS To Buy?
·
· Score: 1
Thanks for the tip, this looks like just the thing.
support for automated offsite backup?
on
What NAS To Buy?
·
· Score: 1
Anyone know of one of these units that supports automated backup via rsync+ssh (or equivalent)? The LinkStations (and TeraStations) seem to be able to do automated backup to another LinkStation on the LAN, and based on the port number seem to use rsync, but I haven't seen anything about securing the connection or even backing up to a regular rsync server.
Ultimately, what I want is a NAS appliance that can do scheduled backups over a secure tunnel to some place like rsync.net, and I want to do it with stock firmware. I know I could easily do this from the shell, but for the application I'm considering, that sort of work is unacceptable.
I'm hesitant to blame the client developers. If someone throws a 10 line script together and runs that an a huge set of files, generating a huge number of requests for the DTD URL, obviously someone along the line ought to be caching that result. In my view, it's ultimately the responsibility of the client, but it's too much complexity to expose and implement for a program you may never run again.
So I look to the libraries. However, the last thing I want is a dozen different libraries putting a dozen different caches in a dozen different non-standard locations. Should the development community come up with a standard for how and where to cache HTTP resources? Is there any fundamental reason libCURL, for example, shouldn't be able to access an object that a webbrowser already cached?
Actually, come to think of it, the solution I like best is to punt and disable caching in all applications, and install a transparent caching proxy like squid either locally or on your LAN.
I don't know enough about the old opt-in system to answer this, so I figured I'd post the question. How does having to register copyright affect works that are subject to constant revision, or collaborative works of the public? Granted, I can't imagine there was a lot of this going on pre-1950s, but it's certainly an issue today.
Consider software code, since that's what I'm most familiar with. Would copyright be registered say with each formal release? How would the incremental changes between releases be protected? Would making a commit to a publicly available repository count as publication? Would going to a more closed development model (not exclusionary, but opt-in development groups, private repositories, only releasing registered builds to the public, etc) provide any protection?
This doesn't apply only to code either. I'm thinking about collaborative literary works, or that graphical quilt posted on/. the other day.
It seems to me that these would be pretty useful even with the current barriers with sector write/erase counts. A lot of what I find myself doing as storage capacities grow and grow is archiving data. In that case, I write something once, and perhaps reorganize it a few times. These flash disks would be perfect for something like that. Similarly, a lot of my installed programs and configurations seldom change, and fast disks could help out there too. Even keeping my documents and personal data on one wouldn't pose much risk.
As a previous poster said, the big advantage to these is reliability. I only backup a small subset (500MB?) of data that I consider to be critical, and I'd love to see the data that's merely important better protected. The speed is nice too, particulary WRT random seek time, but the applications that would benefit most from that are the ones most hindered by the low write/erase count (databases, mail servers,/var &/tmp basically)
Can somebody explain to me how _this_ hack threatens the DRM protected content? AFAICT, itunes decrpyts the content, converts it to this lossless stream, reencrypts it to protect it in transit, and streams it to the AE. There's no threat to the DRM media here at all, since you have to have an unprotected source to start with.
The real threat is that somebody will take this and figure out how to fake being an AE, then you essentially have iTunes doing the work of defeating its own DRM for you. This would have the advantage (from a piracy standpoint) of being fairly hard for Apple to fix via "bug fix updates", unless they built a way to upgrade the AE firmware the same way. That's something I can see people getting into a tizzy about, but for this particular hack I think the useful purposes far outweigh the piracy ones.
I think the suggestions for a whole new RSS specific protocol are somewhat off base. To me, the beauty of an RSS feed is that you don't really need anything special to supply one, just a web server, which you're probably already running, and a script to actually generate the file. I don't think there'd be a lot of success if RSS required special protocols etc. Maybe if you solve the general case of providing a push service and then distribute RSS data over that, but that's a lot of work. A previous poster mentioned using SMTP, and that could be an interesting solution.. Mail updates to an aggregation service and then read via IMAP? I don't make heavy use of RSS, so I don't know if that's a useful way to look at the data or not.
The problem with the server notifying the clients that something has changed doesn't really fix the problem (think thundering herd trying to acquire a mutex), unless it is smart enough to delay notification to clients to even out the load.
I think the real solution is to have the server dictate when the client should check back, and enforce that time delay. If the server just asks nicely, many clients will ignore that. My solution is to use one time passwords that are only valid in a certain window. With the RSS data, the client gets the next password and the window. The passwords would be randomly generated and the algorithm for choosing the window could be arbitrary. Regular HTTP AUTH would be sufficient here. A cron job could manage the list of valid passwords. You'd still have to provide an unprotected stream to get the first password or if the window has expired. To prevent abuse of this, you could limit accesses per IP per day, delay the first window, provide a smaller (empty?) stream, etc.. This could probably provide a backwards compatibility path too. Maybe make it a degraded stream to encourage users to upgrade their clients, or have the first article be "Update your client!" or something..
I got involved with rugby in college, and have to say its quickly become my favorite sport. A baseball game and a few cold beers on a warm summer day is right up there too though. Rugby is an amazing game that's quickly gaining a foothold in the US. Anybody can play - there are positions for slow(er) moving, big and strong guys called forwards (me) and fast, small guys called backs. You don't really need to be of any particular body type, other than be reasonably fit. There's definately a mentality you need to have though. The closets american equivalents are football and soccer, although since it's a more fluid game than football, with few stoppages in play and no substitutions, requires a smaller person with higher endurance. It's a great stress reliever though, as between the game on saturday, the party afterward, and the pain on sunday, there's pretty much no way you can think of work. Except maybe a coworker's face on some poor back you're about to flatten's body, that is:) The best part is that as a player you belong to an international brotherhood, which will nearly always land you a few free pints in a new city if you know where to look.
Another project I have is building a boat with my dad in the back yard. I do this less now that I've moved away, but we should have it in the water this summer. This is a great project because there are so many things to think about, and tasks span many engineering disciplines. Carpentry, plumbing, electrical work, sewing, composite materials, etc.. Its incredibly challenging, because you need to plan every angle of every joint with very few plans. How do you design the waste system so that you flush the head with gray water (from the sink and icebox drains) first, but river water if you run out of gray water? Oh, and no valves or electric pumps allowed. How do you keep the beer cold? The boat is designed for my parents to take up the Erie Canal. A later version will take them, when they retire, on the Great Circle (a large loop of canals and riverways that's essentially the Hudson River to the Erie Canal, across one of the great lakes, down the Mississippi, and back up the Intercoastal Waterway.
My other toy project is restoring a 1969 Saab Sonett. This was Saab's first attempt at a sports car, and is an absolute no-frills coupe. There dash lights and switches are unlabeled (that's why they gave you a manual, duh), the car has an all fiberglass body, and a Ford tractor engine for a motor. You couldn't ask for an easier car to work on though. I just hope I fit into it once I get it finished...
In short, get a hobby that doesn't involve computers! It makes you a more interesting person and helps you lead a more balanced life. Proving that I'm multidisciplined by working on that boat probably directly affected my getting my current job (realtime control software), and if you're lucky enough to find a job where you can apply your hobby, you'll be happy.
Yes and no.. I'd love it if the average driver weren't allowed near the wheel, or if we stepped up driving requirements to requre agressive testing in skid control, poor weather driving, etc. But I'd still trust a human, any human, more than I'd trust this thing.
We've got plenty of safety critical technology aids in cars already. Witness ABS brakes, automatic transmissions, cruise control, etc. They all all aid the driver (in most cases) but don't drive for him. This system starts to drive the car instead. Would you want the computer to jerk the wheel on you? I think controlling the throttle (cruise control) is a bad enough idea. Anything that requires the driver to concentrate less on the path and speed of the vehicle is bad, imho..
Actually, I worry that a system like this could make the driver LESS effective in avoiding the crash than alerting him to it. A sudden acceleration of the body is FAR more disconcerting than a noise or light going off. The time it takes the brain to understand why it just got jerked is probably more than it'd be to just realize the situation and take corrective action with the aid of a buzzer or something. This is moreso when the driver isn't paying attention. If the driver is actively monitoring the impending situation and the car takes action prematurely, he's likely to be less surprised. But if he's already paying attention, then you don't need this stupid thing anyway. An unfocused driver isn't going to be expecting a jerk like that, and is likely to spend more time in the "what the heck was that" mode than "move my limbs we'regunnadie!!!" mode. I'm not a physiologist, I'm just guessing..
I agree with your post to a point, well, this point specificly:
Linux has been widely ported around the town and finding a lowcost CPU that can run Linux (and includes an MMU) is easy.. so theres less need for the ucLinux or other exotic forks. Plain Linux will work well and you in one swoop have drivers for almost any networking or multimedia chip made.
I truly fear (for the sake of the market, not my life [yet]) the companies that say "well, we'll take this processor, these support chips, then just slap linux on top of it and be done with it. After all, all the components we picked have drivers in the kernel." Without someone who truly understands all the pieces they're pulling together, we have the hardware analoge of much of the open source software built today - a mismash of tools in varying states of quality with some glue and new logic slapped on top. This leads to poor (well, I'll say "incompletely tested";-)) software, and would lead to a similar state in hardware.
I'm not at all suggesting that you should develop everything in house so someone understands it all, or that you need someone with a vast amount of knowledge covering all sorts of different chips etc to do embedded linux. But I do think if you're doing hardware integration using linux you should take every driver that touches the hardware you pick as your own. That means analysis, auditing, testing, etc. Many companies don't do this, and its a dangerous practice.
I think that there's truly a need for "trusted" platforms in the embedded market. That is, for a given SBC (single board computer) you can buy a BSP (board support package) that says here is a known tested and working configuration with a linux kernel on it. I think this is where the "exotic kernels" come in. Different projects have different needs, but most of them overlap with somebody else. So it makes sense to have a third party do the integration. This is the way it works with most commercial RTOS - how many companies buy the source to VxWorks, let alone patch and compile it themselves?
The government has finally figured out that (C)OTS (off the shelf) is the way to go, I wonder why so many companies still roll their own?
I feel that it only appears to be fabricatible (is that a word) after it's done.
I agree with you. I said "sufficiently small," though. If I say "this procedure will take this buffer and this length and return a CRC on it" it is fabrication. There may be more than one way to do it, but it there's no way it can affect the architecture. Whole systems are developed to the point where someone just has to fill in the brackets with code that does what its supposed to.
I don't advocate this though. I think that coding and architecture design is a very iterative process, and I believe heavily in refactoring and refinement. However, refactoring is an expensive operation, so I also think that its a good idea to do a preliminary design before you start. Figure out what modules there will be. Identify the data path. Look for places to create common interfaces and code. This is all at a very high level, not even considering language issues. "Okay, I've got a database interface over here, this is the game interface, this is the statistics engine, the game interface talks to the database, fires events to the statistics engine, which stores its data in the database, which is queried by the ui, etc." This is basically the way I like to to my hobby development anyway. My current professional environment is much more structured. Anyway, once I hammer down the data path, I start coding at the beginning. When there's a fork, I put the interface for the fork in, but continue on with the original path I was targetting. Once I reach the point where data gets out, I've now got an easy test case. I can do something and see if my program does the right thing. If it does, I go back and work on a different branch. If not, I can effectively disconnect different modules to isolate the fault. My assumptions about the architecture often change, but having more down on disk when I refactor the interfaces helps me make more informed decisions about what the next interface should look like.
In reality, I think its all the same process. It's just a question of when do you stop designing and start coding and when do you stop refactoring. My feeling on not having any design at all when you start is that its too tempting to stop refactoring when the program becomes "good enough"
I think when this happens the engineers rapidly get out of touch, and the implementer flair along helplessly, cranking out tons of lousy code that's bug-ridden and unmaintainable. Those studies about some programmers being 10x more productive than others... I think they're right on.
Agreed. I don't think for a minute that the engineers shouldn't be involved in the whole cycle. The best use I've seen if where the senior engineers get the trickier (alas, more interesting) parts of the code and the parts where the architecture is just too much of an unknown. Come test time they're heavily involved in integration testing - since they know how the whole system fits together, they're best suited to pull all the different parts together and find out why things don't work.
On the whole, it's still a very young discipline, and lots of people are trying new things. I think it's an exciting time to be in the field.
Compilation, not coding, is the equivalent fabrication. It's easy, brainless, and repeatable - that's why we let the compiler do it.
I disagree. A compiler would be akin to a power tool. There's nothing stopping you from designing/architecting/coding/testing with only a hex editor. There are easy, brainless, and repeatable mechanical fabrication tasks too. They're done by CNC machines. However, that implies the engineering-up-front approach. I maintain that for any sufficiently small component of a program, its purely a fabrication operation. Either it's correct or it isn't - it works, or it doesn't. This is the whole essence of unit testing.
So we put together a heap of sequence diagrams, throw it to some folks overseas, and get 100K lines of code several months later. Hm. I just cite this as an example of what's happening now. I'm not saying its the right way to do it. The trend I think is starting to show is that of separating the architechture engineers from the people doing the actual implementation. There's no reason that the engineers can't do the implementation, and I'm sure many will want to. But because of the different skill requirements between the two operations, I think that a salary gap is going to emerge, and that might push companies towards having fewer engineers and more implementers.
Just a guess anyway.. Never meant to get into a crystal ball gazing mode, I was just chiming in against the hacker-artist romance.
Somehow I like that analogy. A lousy table, a lousy piece of software, that was my analogy.
The carpenter with no real experience and no tools must engineer-on-the-fly. And nobody taught him/her either.
And there's nothing wrong with that, provided that its a learning experience. I wouldn't expect other people to use that table, and that's what happens with a lot of OSS. As the carpenter gains experience and collects more tools, he is able to produce a better table, one that other people might like to use. So too the programmer learns about all the tools available and picks the right one, producing a program that is "good enough." A lot of OSS falls into this category too. The distinguishing trait of a good craftsman is that he always looks to learn more about his craft.
Software can be engineered, but usually is not. To be engineered, most all of the relevant factors have to be taken into account simultaneously. This has approximately the level of difficuly as solving simultaneous equations as opposed to solving the same number of equations sequentially.
You're describing the old "do the engineering before you do anything" way of doing it. It's valid, but I'm not advocating it. I much prefer more engineer-on-the-fly methods. I use them when I develop OSS. I'd argue that all good software is engineered. Yes, you do have to consider the whole problem up front, but you don't have to solve it all. All I'm saying is that you should think about what you're doing before you do it. There is as much room for creativity in software engineering as there is in producing any other mechanical product. However, the creativity belongs at the architecture level, not in the implementation. How many machinists do you see carving their initials into a piece of steel that goes through their mill?
Agreed. I was considering impressionistic and more modern art. If you consider the subset of traditionally artistic fields for which the desired output is a representation of fact, like portrait painting or human sculpture, then that mostly reduces the artist to a craftsman and my analogy should transfer. The carpentry analogy is only clearer due to the ability to separate fabrication and engineering, which is harder to find a parallel for in many artistic media. For certain problems though where there isn't a lot of components and interconnection, etc, like many scripts for instance, the artistic craftsman version probably holds up equally well.
No, it's not just you. I think a lot of self-labeled hackers have a romantic notion of being artists, probably in part because that's an acceptable excuse for eccentricity. You hit it spot on when stating software was functional versus paintings. I think that coding is mostly creative (though not really artistic) in reality. There is significant math behind it, but I think that math is just a language to communicate certain ideas. The people who do actual computer science typically aren't the people doing the implementation. Likewise, in traditional math its not the mathematicians doing the actual implementation work, it's engineers and tradespeople.
If you really want to pick an analogy, I'd pick carpentry. Not finish carpentry, as that's too artistic on the scale, but rather functional carpentry. For instance, a carpenter with no real experience and no tools can build a table out of what they find lying around. Some tables have four different legs of four different sizes, one's attached by childrens paste, and another with a high strength steel bolt. See most OSS packages for the coding analogue. A better carpenter has a few tools and makes a better structure, giving a more functional table. Better programs stand up well provided you embrace their rigid design criteria. A master carpenter might the best looking table and design it such that he could come back and add drawers later or replace it with a bigger top or taller legs.
Carpentry, like software, is mostly about figuring out what pieces you'll need and how to piece them together. That's the essence of engineering. Those who study traditional engineering disciplines often scoff at the idea of software engineering because it violates the traditional way of doing the engineering before construction. That hasn't always been the case, and even today some software is developed by traditional engineering techniques. That's not an invalid way to do it, although it is more expensive. Software engineers are embracing the engineer-on-the-fly paradigm, and that's a new idea that nobody really knows how to teach.
In carpentry as in software, the engineering and fabrication are distinct and separable. I wouldn't consider it unlikely that in the future software architecture (engineering) will be done by a different group of people than the coding (fabrication). This is starting to show up now with many companies doing their architecture in UML and then sending it overseas for actual implementation.
This has run way longer than I wanted, so I'll stop here.. Just a few thoughts on a slow morning.
My sincerest hope is that with all of the embedded applications running on serious hardware now, we'll see an improvement in quality for regular applications. Developing for a sufficiently complex embedded system is indistinguishable for the most part from developing a server application. If you treat your client apps with the same respect you should treat your server apps with, its the same as developing for those too.
I think we're going to see a lot of reuse of existing frameworks and high level abstractions between embedded and traditional applications, and that those frameworks will in turn be hardened to improve their quality. In a lot of situations whole applications will be hardened to run in both variants. This all should in turn benefit the traditional applications. Granted, it still takes a talented developer to produce a quality app no matter how good the underlying framework is. However, I think this type of hardening will help limit the scope of problems to the application code, where the less talented developer is more likely to be able to keep track ot them.
This of course is all dependent on consumers continuing to not tolerate crappy appliances. As long as everyone refuses to consider power cycling as part of normal operating procedure, then I think a lot of improvement is going to occur. However, if this industry explodes, there are going to be a lot of crappy products and consumers are going to lower their expectations, which isn't good for anybody. This is going to be a hot market, but right now I think there's a shortage of engineers who can really work in this domain, and that's probably holding the market back. This is probably good for long term product quality, but bad for someone like me who wants to stop working on defense systems and get into the commercial sector.
Note: This doesn't apply to low powered hardware, hard real time systems, one-of-a-kind systems, etc. Those are a whole different ballgame.
The one thing that I'd like to see changed about packaging is removing the assumption that the package is to be installed for all users. The type of development I do (embedded/dedicated systems mostly) often would benefit from being able to tightly control each user's view of the world. If app A and B each depend on libQ version 3, I don't necessarily WANT to upgrade both of them at the same time if I upgrade libraries. Often I create different users for different projects I'm involved in and manage everything manually, but this obviously isn't a good solution.
Or consider when regular users want to install software onto their account, a package is not an option. Windows has this kind of right with the All Users concept, although many packages break when trying to install them as a regular user. In the case of multiple users with the same package installed locally, some drive space optimization can likely be done with symlinks. I think Stow does something similar.
This isn't a problem with linux distributions per se, its a reflection of the unix mentality of one administrator and all users presented with the same environment. I'd like to see a packaging system that lets you install packages to your home directory if you wish, or become root if you want to make the package available to everyone. I really think this is possible to do, although it would mean breaking the FHS, and has the added benefit of reducing the time a user has to spend as root.
A bit of consolation: I think I was in on the same Cendyne rebate as you. $50, and I think it was around Christmas. I just got my check in the mail last week, so don't give up hope yet..
I too prefer a full size button to the down position of the scroll wheel. I still haven't found one that I don't often scroll-and-click when I want to just click or accidentally click when I want to scroll. I do like the wheel once in a while though. Is anybody making a mouse with the wheel in the thumb position? I've seen buttons there, but no wheels. I don't care if its optical or not, ball mice treat me just fine..
The thing that intrigues me most about the MANs that have been springing up is the potential for communicating with my physical neighbors at high speeds. This is a point that I haven't often seen in these slashdot discussions. Well, at least not outside the occasional reference to a city wide LAN party. To me, the benefits of this are clear, although I come from a small town background and am used to developing close relationships with the people who live near me. If you're the type to lock yourself in your lair and get all your interaction from the net, then you might not care, but I think it'd be nice to have uncapped access to the local TV station, or even just to have a fast pipe next door or across town.
I'm an embedded systems guy by trade, so I'm no network engineer. Sure, I've got some certs and some pro bono network admin work under my belt, but I don't know what goes into admining a network of this size. I guess what I'd like to know is what the restrictions are at this time, be they financial or technical, to moving the traffic shaping from the edge (eg, customer equipment, capping cable modem rates, lowering rates at the DSLAM below what is technically possible, etc) to the peering points, or even just at the long haul links. Is it just the extra horsepower required by the routers? Or would a network organized like this cost more to administrate? I don't see how it would, at least not in bandwidth costs. Or is it simply a matter of there not being a need/current use for this type of setup? Anybody shed some light on this for me?
The last time I was poking around the kernel source SRPM for a Mandrake install, the stock linux-2.4.? tarball was in there (along with all the other patches they apply to it).. Your distribution may have the same thing. Unpack the SRPM to get a linux tarball, unpack that to get the source tree, then download and install the patches to bring it up to the version you want to run.
Granted, this doesn't answer your question, but it may ease the download times a bit..
I was looking into this a while ago in the context of sharing two connections to increase bandwidth and reliability. You won't be able to get upstream routing, so most people doing this sort of thing just use some sort of failover script.
In addition, you can configure the routing table to basically use round robin on the two lines, so one connection will go out over one line, and the next over another. Note that this is at the connection/session level, not the packet level. So once you start a download (or upload) those packets will always come in (or go out) over the same interface. Your load balance won't be as good as packet by packet routing, but you should still see increased throughput. Might as well make use of the bandwidth, if you've got it..
Here's an idea you can probably steal from millions of teachers across the country for teaching the scientific method:
Have them write down instructions for making a peanut butter and jelly sandwich. You then follow these directions exactly, as a computer would. Likely to get a laugh out of them when you start spreading the peanut butter on the bread without taking it out of the bag first.
This teaches the fundamental rule in computers - they "do what they're told." exactly. without interpretation.
Slashdot Mirror
Thanks for the tip, this looks like just the thing.
Anyone know of one of these units that supports automated backup via rsync+ssh (or equivalent)? The LinkStations (and TeraStations) seem to be able to do automated backup to another LinkStation on the LAN, and based on the port number seem to use rsync, but I haven't seen anything about securing the connection or even backing up to a regular rsync server.
Ultimately, what I want is a NAS appliance that can do scheduled backups over a secure tunnel to some place like rsync.net, and I want to do it with stock firmware. I know I could easily do this from the shell, but for the application I'm considering, that sort of work is unacceptable.
I'm hesitant to blame the client developers. If someone throws a 10 line script together and runs that an a huge set of files, generating a huge number of requests for the DTD URL, obviously someone along the line ought to be caching that result. In my view, it's ultimately the responsibility of the client, but it's too much complexity to expose and implement for a program you may never run again.
So I look to the libraries. However, the last thing I want is a dozen different libraries putting a dozen different caches in a dozen different non-standard locations. Should the development community come up with a standard for how and where to cache HTTP resources? Is there any fundamental reason libCURL, for example, shouldn't be able to access an object that a webbrowser already cached?
Actually, come to think of it, the solution I like best is to punt and disable caching in all applications, and install a transparent caching proxy like squid either locally or on your LAN.
I don't know enough about the old opt-in system to answer this, so I figured I'd post the question. How does having to register copyright affect works that are subject to constant revision, or collaborative works of the public? Granted, I can't imagine there was a lot of this going on pre-1950s, but it's certainly an issue today.
/. the other day.
Consider software code, since that's what I'm most familiar with. Would copyright be registered say with each formal release? How would the incremental changes between releases be protected? Would making a commit to a publicly available repository count as publication? Would going to a more closed development model (not exclusionary, but opt-in development groups, private repositories, only releasing registered builds to the public, etc) provide any protection?
This doesn't apply only to code either. I'm thinking about collaborative literary works, or that graphical quilt posted on
Something to chew on..
It seems to me that these would be pretty useful even with the current barriers with sector write/erase counts. A lot of what I find myself doing as storage capacities grow and grow is archiving data. In that case, I write something once, and perhaps reorganize it a few times. These flash disks would be perfect for something like that. Similarly, a lot of my installed programs and configurations seldom change, and fast disks could help out there too. Even keeping my documents and personal data on one wouldn't pose much risk.
/var & /tmp basically)
As a previous poster said, the big advantage to these is reliability. I only backup a small subset (500MB?) of data that I consider to be critical, and I'd love to see the data that's merely important better protected. The speed is nice too, particulary WRT random seek time, but the applications that would benefit most from that are the ones most hindered by the low write/erase count (databases, mail servers,
Can somebody explain to me how _this_ hack threatens the DRM protected content? AFAICT, itunes decrpyts the content, converts it to this lossless stream, reencrypts it to protect it in transit, and streams it to the AE. There's no threat to the DRM media here at all, since you have to have an unprotected source to start with.
The real threat is that somebody will take this and figure out how to fake being an AE, then you essentially have iTunes doing the work of defeating its own DRM for you. This would have the advantage (from a piracy standpoint) of being fairly hard for Apple to fix via "bug fix updates", unless they built a way to upgrade the AE firmware the same way. That's something I can see people getting into a tizzy about, but for this particular hack I think the useful purposes far outweigh the piracy ones.
Just a thought.
I think the suggestions for a whole new RSS specific protocol are somewhat off base. To me, the beauty of an RSS feed is that you don't really need anything special to supply one, just a web server, which you're probably already running, and a script to actually generate the file. I don't think there'd be a lot of success if RSS required special protocols etc. Maybe if you solve the general case of providing a push service and then distribute RSS data over that, but that's a lot of work. A previous poster mentioned using SMTP, and that could be an interesting solution.. Mail updates to an aggregation service and then read via IMAP? I don't make heavy use of RSS, so I don't know if that's a useful way to look at the data or not.
The problem with the server notifying the clients that something has changed doesn't really fix the problem (think thundering herd trying to acquire a mutex), unless it is smart enough to delay notification to clients to even out the load.
I think the real solution is to have the server dictate when the client should check back, and enforce that time delay. If the server just asks nicely, many clients will ignore that. My solution is to use one time passwords that are only valid in a certain window. With the RSS data, the client gets the next password and the window. The passwords would be randomly generated and the algorithm for choosing the window could be arbitrary. Regular HTTP AUTH would be sufficient here. A cron job could manage the list of valid passwords. You'd still have to provide an unprotected stream to get the first password or if the window has expired. To prevent abuse of this, you could limit accesses per IP per day, delay the first window, provide a smaller (empty?) stream, etc.. This could probably provide a backwards compatibility path too. Maybe make it a degraded stream to encourage users to upgrade their clients, or have the first article be "Update your client!" or something..
Just a few thoughts.. Anyone care to comment?
Another project I have is building a boat with my dad in the back yard. I do this less now that I've moved away, but we should have it in the water this summer. This is a great project because there are so many things to think about, and tasks span many engineering disciplines. Carpentry, plumbing, electrical work, sewing, composite materials, etc.. Its incredibly challenging, because you need to plan every angle of every joint with very few plans. How do you design the waste system so that you flush the head with gray water (from the sink and icebox drains) first, but river water if you run out of gray water? Oh, and no valves or electric pumps allowed. How do you keep the beer cold? The boat is designed for my parents to take up the Erie Canal. A later version will take them, when they retire, on the Great Circle (a large loop of canals and riverways that's essentially the Hudson River to the Erie Canal, across one of the great lakes, down the Mississippi, and back up the Intercoastal Waterway.
My other toy project is restoring a 1969 Saab Sonett. This was Saab's first attempt at a sports car, and is an absolute no-frills coupe. There dash lights and switches are unlabeled (that's why they gave you a manual, duh), the car has an all fiberglass body, and a Ford tractor engine for a motor. You couldn't ask for an easier car to work on though. I just hope I fit into it once I get it finished...
In short, get a hobby that doesn't involve computers! It makes you a more interesting person and helps you lead a more balanced life. Proving that I'm multidisciplined by working on that boat probably directly affected my getting my current job (realtime control software), and if you're lucky enough to find a job where you can apply your hobby, you'll be happy.
Cheers!
We've got plenty of safety critical technology aids in cars already. Witness ABS brakes, automatic transmissions, cruise control, etc. They all all aid the driver (in most cases) but don't drive for him. This system starts to drive the car instead. Would you want the computer to jerk the wheel on you? I think controlling the throttle (cruise control) is a bad enough idea. Anything that requires the driver to concentrate less on the path and speed of the vehicle is bad, imho..
Actually, I worry that a system like this could make the driver LESS effective in avoiding the crash than alerting him to it. A sudden acceleration of the body is FAR more disconcerting than a noise or light going off. The time it takes the brain to understand why it just got jerked is probably more than it'd be to just realize the situation and take corrective action with the aid of a buzzer or something. This is moreso when the driver isn't paying attention. If the driver is actively monitoring the impending situation and the car takes action prematurely, he's likely to be less surprised. But if he's already paying attention, then you don't need this stupid thing anyway. An unfocused driver isn't going to be expecting a jerk like that, and is likely to spend more time in the "what the heck was that" mode than "move my limbs we'regunnadie!!!" mode. I'm not a physiologist, I'm just guessing..
I truly fear (for the sake of the market, not my life [yet]) the companies that say "well, we'll take this processor, these support chips, then just slap linux on top of it and be done with it. After all, all the components we picked have drivers in the kernel." Without someone who truly understands all the pieces they're pulling together, we have the hardware analoge of much of the open source software built today - a mismash of tools in varying states of quality with some glue and new logic slapped on top. This leads to poor (well, I'll say "incompletely tested" ;-)) software, and would lead to a similar state in hardware.
I'm not at all suggesting that you should develop everything in house so someone understands it all, or that you need someone with a vast amount of knowledge covering all sorts of different chips etc to do embedded linux. But I do think if you're doing hardware integration using linux you should take every driver that touches the hardware you pick as your own. That means analysis, auditing, testing, etc. Many companies don't do this, and its a dangerous practice.
I think that there's truly a need for "trusted" platforms in the embedded market. That is, for a given SBC (single board computer) you can buy a BSP (board support package) that says here is a known tested and working configuration with a linux kernel on it. I think this is where the "exotic kernels" come in. Different projects have different needs, but most of them overlap with somebody else. So it makes sense to have a third party do the integration. This is the way it works with most commercial RTOS - how many companies buy the source to VxWorks, let alone patch and compile it themselves?
The government has finally figured out that (C)OTS (off the shelf) is the way to go, I wonder why so many companies still roll their own?
You're entitled
I feel that it only appears to be fabricatible (is that a word) after it's done.
I agree with you. I said "sufficiently small," though. If I say "this procedure will take this buffer and this length and return a CRC on it" it is fabrication. There may be more than one way to do it, but it there's no way it can affect the architecture. Whole systems are developed to the point where someone just has to fill in the brackets with code that does what its supposed to.
I don't advocate this though. I think that coding and architecture design is a very iterative process, and I believe heavily in refactoring and refinement. However, refactoring is an expensive operation, so I also think that its a good idea to do a preliminary design before you start. Figure out what modules there will be. Identify the data path. Look for places to create common interfaces and code. This is all at a very high level, not even considering language issues. "Okay, I've got a database interface over here, this is the game interface, this is the statistics engine, the game interface talks to the database, fires events to the statistics engine, which stores its data in the database, which is queried by the ui, etc." This is basically the way I like to to my hobby development anyway. My current professional environment is much more structured. Anyway, once I hammer down the data path, I start coding at the beginning. When there's a fork, I put the interface for the fork in, but continue on with the original path I was targetting. Once I reach the point where data gets out, I've now got an easy test case. I can do something and see if my program does the right thing. If it does, I go back and work on a different branch. If not, I can effectively disconnect different modules to isolate the fault. My assumptions about the architecture often change, but having more down on disk when I refactor the interfaces helps me make more informed decisions about what the next interface should look like.
In reality, I think its all the same process. It's just a question of when do you stop designing and start coding and when do you stop refactoring. My feeling on not having any design at all when you start is that its too tempting to stop refactoring when the program becomes "good enough"
I think when this happens the engineers rapidly get out of touch, and the implementer flair along helplessly, cranking out tons of lousy code that's bug-ridden and unmaintainable. Those studies about some programmers being 10x more productive than others... I think they're right on.
Agreed. I don't think for a minute that the engineers shouldn't be involved in the whole cycle. The best use I've seen if where the senior engineers get the trickier (alas, more interesting) parts of the code and the parts where the architecture is just too much of an unknown. Come test time they're heavily involved in integration testing - since they know how the whole system fits together, they're best suited to pull all the different parts together and find out why things don't work.
On the whole, it's still a very young discipline, and lots of people are trying new things. I think it's an exciting time to be in the field.
Cheers!
I disagree. A compiler would be akin to a power tool. There's nothing stopping you from designing/architecting/coding/testing with only a hex editor. There are easy, brainless, and repeatable mechanical fabrication tasks too. They're done by CNC machines. However, that implies the engineering-up-front approach. I maintain that for any sufficiently small component of a program, its purely a fabrication operation. Either it's correct or it isn't - it works, or it doesn't. This is the whole essence of unit testing.
So we put together a heap of sequence diagrams, throw it to some folks overseas, and get 100K lines of code several months later. Hm.
I just cite this as an example of what's happening now. I'm not saying its the right way to do it. The trend I think is starting to show is that of separating the architechture engineers from the people doing the actual implementation. There's no reason that the engineers can't do the implementation, and I'm sure many will want to. But because of the different skill requirements between the two operations, I think that a salary gap is going to emerge, and that might push companies towards having fewer engineers and more implementers.
Just a guess anyway.. Never meant to get into a crystal ball gazing mode, I was just chiming in against the hacker-artist romance.
A lousy table, a lousy piece of software, that was my analogy.
The carpenter with no real experience and no tools must engineer-on-the-fly. And nobody taught him/her either.
And there's nothing wrong with that, provided that its a learning experience. I wouldn't expect other people to use that table, and that's what happens with a lot of OSS. As the carpenter gains experience and collects more tools, he is able to produce a better table, one that other people might like to use. So too the programmer learns about all the tools available and picks the right one, producing a program that is "good enough." A lot of OSS falls into this category too. The distinguishing trait of a good craftsman is that he always looks to learn more about his craft.
Software can be engineered, but usually is not. To be engineered, most all of the relevant factors have to be taken into account simultaneously. This has approximately the level of difficuly as solving simultaneous equations as opposed to solving the same number of equations sequentially. You're describing the old "do the engineering before you do anything" way of doing it. It's valid, but I'm not advocating it. I much prefer more engineer-on-the-fly methods. I use them when I develop OSS. I'd argue that all good software is engineered. Yes, you do have to consider the whole problem up front, but you don't have to solve it all. All I'm saying is that you should think about what you're doing before you do it. There is as much room for creativity in software engineering as there is in producing any other mechanical product. However, the creativity belongs at the architecture level, not in the implementation. How many machinists do you see carving their initials into a piece of steel that goes through their mill?
Agreed. I was considering impressionistic and more modern art. If you consider the subset of traditionally artistic fields for which the desired output is a representation of fact, like portrait painting or human sculpture, then that mostly reduces the artist to a craftsman and my analogy should transfer. The carpentry analogy is only clearer due to the ability to separate fabrication and engineering, which is harder to find a parallel for in many artistic media. For certain problems though where there isn't a lot of components and interconnection, etc, like many scripts for instance, the artistic craftsman version probably holds up equally well.
If you really want to pick an analogy, I'd pick carpentry. Not finish carpentry, as that's too artistic on the scale, but rather functional carpentry. For instance, a carpenter with no real experience and no tools can build a table out of what they find lying around. Some tables have four different legs of four different sizes, one's attached by childrens paste, and another with a high strength steel bolt. See most OSS packages for the coding analogue. A better carpenter has a few tools and makes a better structure, giving a more functional table. Better programs stand up well provided you embrace their rigid design criteria. A master carpenter might the best looking table and design it such that he could come back and add drawers later or replace it with a bigger top or taller legs.
Carpentry, like software, is mostly about figuring out what pieces you'll need and how to piece them together. That's the essence of engineering. Those who study traditional engineering disciplines often scoff at the idea of software engineering because it violates the traditional way of doing the engineering before construction. That hasn't always been the case, and even today some software is developed by traditional engineering techniques. That's not an invalid way to do it, although it is more expensive. Software engineers are embracing the engineer-on-the-fly paradigm, and that's a new idea that nobody really knows how to teach.
In carpentry as in software, the engineering and fabrication are distinct and separable. I wouldn't consider it unlikely that in the future software architecture (engineering) will be done by a different group of people than the coding (fabrication). This is starting to show up now with many companies doing their architecture in UML and then sending it overseas for actual implementation.
This has run way longer than I wanted, so I'll stop here.. Just a few thoughts on a slow morning.
I think we're going to see a lot of reuse of existing frameworks and high level abstractions between embedded and traditional applications, and that those frameworks will in turn be hardened to improve their quality. In a lot of situations whole applications will be hardened to run in both variants. This all should in turn benefit the traditional applications. Granted, it still takes a talented developer to produce a quality app no matter how good the underlying framework is. However, I think this type of hardening will help limit the scope of problems to the application code, where the less talented developer is more likely to be able to keep track ot them.
This of course is all dependent on consumers continuing to not tolerate crappy appliances. As long as everyone refuses to consider power cycling as part of normal operating procedure, then I think a lot of improvement is going to occur. However, if this industry explodes, there are going to be a lot of crappy products and consumers are going to lower their expectations, which isn't good for anybody. This is going to be a hot market, but right now I think there's a shortage of engineers who can really work in this domain, and that's probably holding the market back. This is probably good for long term product quality, but bad for someone like me who wants to stop working on defense systems and get into the commercial sector.
Note: This doesn't apply to low powered hardware, hard real time systems, one-of-a-kind systems, etc. Those are a whole different ballgame.
Or consider when regular users want to install software onto their account, a package is not an option. Windows has this kind of right with the All Users concept, although many packages break when trying to install them as a regular user. In the case of multiple users with the same package installed locally, some drive space optimization can likely be done with symlinks. I think Stow does something similar.
This isn't a problem with linux distributions per se, its a reflection of the unix mentality of one administrator and all users presented with the same environment. I'd like to see a packaging system that lets you install packages to your home directory if you wish, or become root if you want to make the package available to everyone. I really think this is possible to do, although it would mean breaking the FHS, and has the added benefit of reducing the time a user has to spend as root.
Any thoughts?
A bit of consolation: I think I was in on the same Cendyne rebate as you. $50, and I think it was around Christmas. I just got my check in the mail last week, so don't give up hope yet..
I too prefer a full size button to the down position of the scroll wheel. I still haven't found one that I don't often scroll-and-click when I want to just click or accidentally click when I want to scroll. I do like the wheel once in a while though. Is anybody making a mouse with the wheel in the thumb position? I've seen buttons there, but no wheels. I don't care if its optical or not, ball mice treat me just fine..
The thing that intrigues me most about the MANs that have been springing up is the potential for communicating with my physical neighbors at high speeds. This is a point that I haven't often seen in these slashdot discussions. Well, at least not outside the occasional reference to a city wide LAN party. To me, the benefits of this are clear, although I come from a small town background and am used to developing close relationships with the people who live near me. If you're the type to lock yourself in your lair and get all your interaction from the net, then you might not care, but I think it'd be nice to have uncapped access to the local TV station, or even just to have a fast pipe next door or across town.
I'm an embedded systems guy by trade, so I'm no network engineer. Sure, I've got some certs and some pro bono network admin work under my belt, but I don't know what goes into admining a network of this size. I guess what I'd like to know is what the restrictions are at this time, be they financial or technical, to moving the traffic shaping from the edge (eg, customer equipment, capping cable modem rates, lowering rates at the DSLAM below what is technically possible, etc) to the peering points, or even just at the long haul links. Is it just the extra horsepower required by the routers? Or would a network organized like this cost more to administrate? I don't see how it would, at least not in bandwidth costs. Or is it simply a matter of there not being a need/current use for this type of setup? Anybody shed some light on this for me?
Not only is this the third time today this article has been posted, but the second time by CmdrTaco.. I hate april fools day.
The last time I was poking around the kernel source SRPM for a Mandrake install, the stock linux-2.4.? tarball was in there (along with all the other patches they apply to it).. Your distribution may have the same thing. Unpack the SRPM to get a linux tarball, unpack that to get the source tree, then download and install the patches to bring it up to the version you want to run.
Granted, this doesn't answer your question, but it may ease the download times a bit..
In addition, you can configure the routing table to basically use round robin on the two lines, so one connection will go out over one line, and the next over another. Note that this is at the connection/session level, not the packet level. So once you start a download (or upload) those packets will always come in (or go out) over the same interface. Your load balance won't be as good as packet by packet routing, but you should still see increased throughput. Might as well make use of the bandwidth, if you've got it..
Have them write down instructions for making a peanut butter and jelly sandwich. You then follow these directions exactly, as a computer would. Likely to get a laugh out of them when you start spreading the peanut butter on the bread without taking it out of the bag first.
This teaches the fundamental rule in computers - they "do what they're told." exactly. without interpretation.
Food for thought.. (Pun intended)