Most low end hardware firewalls are actually just NAT boxes that give a firewall "effect." Basically the firewall doesn't know how to route a packet to a machine inside the network unless some routing context has already been created by an outbound connection.
The "DMZ" (it ain't really a DMZ because there is no additional port/interface with its own firewall rules) feature typically in these firewalls is actually just a forward-all inbound to a given machine. So any inbound connection that doesn't have any specific port forward associated with it now has a place to go. This makes many NAT unfriendly applications work, so it is often turned on for gaming, the badly designed ICQ protocol and other purposes.
Just mentioning that to avoid confusion. I happen to have come up with concept for one of the first of these low end consumer firewalls (though I obviously didn't invent NAT... just the idea of a low-end consumer firewall appliance) and it was our marketing at Beadlenet that muddied the waters by calling the feature "DMZ."
Well the disconnect is that most people think of firewalls as what protects them from the Internet. You are more interested in protecting your network from your users. That is a worthy goal.
You should still have a separate box to run the firewall on the edge of the network. But if you have stupid users or strict policies for use, you could run local software firewalls.
1) Software is more complex than a car. 2) Your car *does* needs more men to maintain it than a computer system does. It's just designed to wear out equipment/ material at regular intervals so the maintenance can be done periodically instead of intermittently 3) No one is actively working to break-in/destroy your car from a remote location... and those that try to do it locally will succeed. Computers on the network have to be safe from break-in in all cases (but they too are usually vulnerable if thief is at the keyboard).
Okay, I'll bite. You're saying that if you have a magic nicely shaped appliance it somehow won't require security patches like a Linux box does?
All software has bugs. All software, particularly that which runs on the edge of the network, must be maintained with patches. All hardware networking solutions of any reasonable complexity like a router or firewall run software. Therefore they too must be patched from time to time.
At least with a Debian box you could put a cron job that automatically apt-get's latest patches for itself, if you wanted to have a box which maintains itself (I would rather have an admin maintaining it, but whatever...).
This may or may not be a feature of whatever appliance the parent thinks is a better alternative.
So you're saying that his customer should avoid vendor lock-in by locking in with a proprietary vendor?
Hmm... Linux routers and firewall rules are well described on the web. Any "competent network engineer" as you describe him/her is likely able to read...
The check-in/check-out is how the Sony software works for the higher quality ATRAC files. It is a DRM system in the software that downloads music to the MP3 player. I would think they do something similar when you want to get ATRAC files out of the library. But if you're using simple burner though, I guess you don't see the check-in/out stuff.
Anyway you should check out RealOne to see if it does what you want. Personally I wouldn't mess with ATRAC format since it typically involves DRM. Rip once, rip right to OGG Flac, then transcode to the format of your player.
Here's an idea... Will Nero burn ATRAC files to disc?
My brother has MiniDisc and we use RealOne player to download MP3's to the device. Much easier to use than the Sony tools that came with it, since you can avoid all the check-in/out junk.
Now we were using MP3s, it may or may not work with ATRAC. Why do you care about ATRAC anyway? Doesn't it play MP3?
I use Ion 2... either a window should be visible or it shouldn't (though the tab should show)... some random visible portion of a window might be the only metaphor available for desktops in meatspace but I am growing accustomed to a nice orderly gui desktop.
It obviously requires an artificial intelligence of some sort... somehow the device seems to anticipate who it is you want to talk to and establishes up a 1-1 link. Otherwise if everybody was on one partyline you can imagine the level of chatter. Perhaps the idea is the computer is always following the context of conversations, or it doesn't actually interrupt the person you are talking to until it collects enough context to decide.
With enough processing power I think that's how one would do it though...
On the contrary it seems a heck of a lot more functional than typical desktop GUIs...
Every window opened full screen, important messages in large readable text, it has a very interactive feel. It gives the impression of an adaptable, efficient two dimensional interface for communicating with an embedded system. The Lines clearly delineate portions of the display of interest, the text is large enough to be seen and pressed with fingers, etc... they did put thought into the general look and feel and I think Okuda did a great job.
But generally you should just think of them as props, they in general aren't meant to be looked at up close so don't be too "upset."
You know what? The same thing happened to programmers as our industry started to mature.
Not all that long ago, you would hear about kids making some video game and becoming instant millionaires. Or small startups that sold so many copies of xyz spreadsheet that they became millionaires. Royalties/license fees are great.
Then with the maturing of the industry we realized that it is really hard to compete with larger software houses. So we've gone one of two ways: we work for a proprietary software house for a reasonable wage (no one becomes millionaires, generally unless they are an Owner), either while being on contract or salary.
A large number of civilized programmers are actually giving away their code in the F/OSS community because that is what they like to do.
It just turns out that the reality today is you're probably going to just be paid for the "performance" or perhaps just with gratitude.
Get used to it... things change. Copyright attempts to artificially make information a marketable quantity. It no longer is and the Network is going to enforce its own laws. You'll just have to work for every buck like the rest of us.
There is no way to use exceptions that is generally readable. And rampant uncontrollable gotos, which is a significant aspect of exceptions isn't avoidable (please enlighten me otherwise).
And whether libraries generate exceptions instead of return codes isn't typically under your control. It's under the control of the creator of the library.
Any exception handler is going to be a nested block of code. and if you allow an outer exception handler to be reached you really have a totally unpredictable result as far as the curent state of the machine. You have no choice but to write ugly code if exceptions are around.
Add to that C#'s interminable nesting of classes generally, and you have code moving several levels deep to the right.
Exceptions are worse than gotos... at least you know when and where the goto is going to go...
Exceptions break normal program flow.
They are an unstoppable evil force and anyone that thinks otherwise is simply misinformed.
Also handling API's which normally generate "exceptions" (seem more like the rule than the exception...) makes every piece of code that uses the API look like a nested mess of spaghetti (hmmm... sort of like any given C# program...)
For serious CPU confusion hitting a low level exception handler makes sense... null pointer deref, divide by zero, invalid instruction...
But exceptions are an evil bane of modern languages and I can only hope they are a temporary fad.
Keep in mind though with less shyness and actor friends he'll get figure out how to attract attention from females too early and never build up the solid hacking skills necessary to be a world class geek.
If that's what you want, fine... but you may be ruining him for his true calling.
> You missed the point. Well, this time you made some:-)
>The customers don't give a shit. A smallish medical practice has something like $2 million in "sales" per year. $5-20k is pissing in the ocean.
Customers don't care about saving 20K in licensing fees? With each upgrade? I'll bet plenty of small practices do. Anyway, money is money.
>Doctors want their shit to work so the insurance companies pay for his services. That's it. They do not care about open source and likely prefer to deal with the vendors that they know about.
That's a good point: Doctors don't care about FOSS. What they do care about is getting a good product at a reasonable price, just like any business does. But I don't think FOSS implies crap. In fact, once it is stable the quality is typically high. I'm not buying the implied argument here that FOSS doesn't work.
>The other thing is that EDI and other standards that vertical applications must adhere to are not free. The standards and specs are not open and often cost signifigant sums of money.
Standards are not patents. You only have to pay once to get the standard, so buying all the standards necessary for a FOSS is possible. They could also be donated by third parties. Also there are typically publicly available drafts of standards leading up to the final standard which are public. These are normally sufficient for getting development 90% of the way along.
>You do not understand how vertical markets work at all.
Ah, disappointment... I was expecting you to disagree with me factually in some way...
Of course the existing vendors don't care about FOSS (other than to be afraid of it). Why should they? FOSS will disrupt their proprietary business model, as it is currently disrupting all proprietary software business models.
Yeah, FOSS software is how customers will be freed from being violated (to use your term) by license costs, although not support costs. There aren't going to be a bunch of developers giving out free support on IRC for this kind of specialty software. It ain't the fun stuff, that's for sure. As you say it's nothing complicated... that means boring work.
And well, it turns out that it is good for the doctor who can go to anybody for support. But if you've ever done any contracting you would know that once a customer has a vendor they trust who offers them a rate that fits their budget, they tend to stay with that vendor barring some cataclysm or bad service.
Think of it this way... FOSS gives the customer what they want... reasonable prices and no vendor lock-in. And it breaks the market wide open for anyone who wants to enter it since there are no complicated license deals/agreements. It's called "competition" and though the entrenched, established vendors would rather not have any, efforts like this seem to imply it is coming.
There is a lot of money in this niche market. Making a GPLd billing package would be the thin edge of the wedge to getting FOSS developers in the door.
FOSS developers don't work for nothing (some do). The ideal model is work for hire improving and releasing GPL'd source code. But yeah somewhere along the way in every FOSS project somebody has to give away the code to get the ball rolling. The code stays free but if an end user wants a custom change, they have to pay. The could pay the company who the bought the proprietary software to change their own system (big $$$'s since they have a monopoly on their own code), or they can go to the original developers of the GPL'd code, or even hire anyone else who is willing to learn the code base.
With FOSS development model it is true that we won't make megabucks off of royalty and license fees. But for the individual developer I think it has been that way for quite a while, anyway.
Slashdot Mirror
Uh, no...
Say I want to add a hardware DMZ port.
Where do I shove the ethernet card into that little blue box?
And I boot my firewall from CD, and there's no hard drive. How do I make this Linksys box boot from a write-only medium?
Not so customizable it seems as my beige box...
QED
Most low end hardware firewalls are actually just NAT boxes that give a firewall "effect." Basically the firewall doesn't know how to route a packet to a machine inside the network unless some routing context has already been created by an outbound connection.
The "DMZ" (it ain't really a DMZ because there is no additional port/interface with its own firewall rules) feature typically in these firewalls is actually just a forward-all inbound to a given machine. So any inbound connection that doesn't have any specific port forward associated with it now has a place to go. This makes many NAT unfriendly applications work, so it is often turned on for gaming, the badly designed ICQ protocol and other purposes.
Just mentioning that to avoid confusion. I happen to have come up with concept for one of the first of these low end consumer firewalls (though I obviously didn't invent NAT... just the idea of a low-end consumer firewall appliance) and it was our marketing at Beadlenet that muddied the waters by calling the feature "DMZ."
It's not necessarily even an issue of buying something. I used an old pentium II box running a customized Linux firewall distro to protect my network.
Much more customizable than a Linksys box. And you can add edge VPN at no cost.
With an extra card and some configuration you have a DMZ port.
You would have to spend >$300 for a low end Cisco router and VPN is probably extra...
Well the disconnect is that most people think of firewalls as what protects them from the Internet. You are more interested in protecting your network from your users. That is a worthy goal.
You should still have a separate box to run the firewall on the edge of the network. But if you have stupid users or strict policies for use, you could run local software firewalls.
They are independent issues...
1) Software is more complex than a car.
2) Your car *does* needs more men to maintain it than a computer system does. It's just designed to wear out equipment/ material at regular intervals so the maintenance can be done periodically instead of intermittently
3) No one is actively working to break-in/destroy your car from a remote location... and those that try to do it locally will succeed. Computers on the network have to be safe from break-in in all cases (but they too are usually vulnerable if thief is at the keyboard).
And probably some other reasons...
Okay, I'll bite. You're saying that if you have a magic nicely shaped appliance it somehow won't require security patches like a Linux box does?
All software has bugs. All software, particularly that which runs on the edge of the network, must be maintained with patches. All hardware networking solutions of any reasonable complexity like a router or firewall run software. Therefore they too must be patched from time to time.
At least with a Debian box you could put a cron job that automatically apt-get's latest patches for itself, if you wanted to have a box which maintains itself (I would rather have an admin maintaining it, but whatever...).
This may or may not be a feature of whatever appliance the parent thinks is a better alternative.
So you're saying that his customer should avoid vendor lock-in by locking in with a proprietary vendor?
Hmm... Linux routers and firewall rules are well described on the web. Any "competent network engineer" as you describe him/her is likely able to read...
The check-in/check-out is how the Sony software works for the higher quality ATRAC files. It is a DRM system in the software that downloads music to the MP3 player. I would think they do something similar when you want to get ATRAC files out of the library. But if you're using simple burner though, I guess you don't see the check-in/out stuff.
Anyway you should check out RealOne to see if it does what you want. Personally I wouldn't mess with ATRAC format since it typically involves DRM. Rip once, rip right to OGG Flac, then transcode to the format of your player.
Here's an idea... Will Nero burn ATRAC files to disc?
My brother has MiniDisc and we use RealOne player to download MP3's to the device. Much easier to use than the Sony tools that came with it, since you can avoid all the check-in/out junk.
Now we were using MP3s, it may or may not work with ATRAC. Why do you care about ATRAC anyway? Doesn't it play MP3?
Agreed... could be something it ate. Or it's just a particularly ornery lobster.
My hypothesis would be a genetic component there, which the antifreeze protein you are suggesting would fit with.
If true they could do some selective breeding and increase the survival rate...
Of course, that presumes the ones that survive can still breed, or that usable reproductive material is extracted before freezing.
I use Ion 2... either a window should be visible or it shouldn't (though the tab should show)... some random visible portion of a window might be the only metaphor available for desktops in meatspace but I am growing accustomed to a nice orderly gui desktop.
Fantastic! The only pacing item seems to be the Heisenberg Compensators... and some minor metaphysical issues, but other than that, good to go!
It obviously requires an artificial intelligence of some sort... somehow the device seems to anticipate who it is you want to talk to and establishes up a 1-1 link. Otherwise if everybody was on one partyline you can imagine the level of chatter. Perhaps the idea is the computer is always following the context of conversations, or it doesn't actually interrupt the person you are talking to until it collects enough context to decide.
With enough processing power I think that's how one would do it though...
On the contrary it seems a heck of a lot more functional than typical desktop GUIs...
Every window opened full screen, important messages in large readable text, it has a very interactive feel. It gives the impression of an adaptable, efficient two dimensional interface for communicating with an embedded system. The Lines clearly delineate portions of the display of interest, the text is large enough to be seen and pressed with fingers, etc... they did put thought into the general look and feel and I think Okuda did a great job.
But generally you should just think of them as props, they in general aren't meant to be looked at up close so don't be too "upset."
You know what? The same thing happened to programmers as our industry started to mature.
Not all that long ago, you would hear about kids making some video game and becoming instant millionaires. Or small startups that sold so many copies of xyz spreadsheet that they became millionaires. Royalties/license fees are great.
Then with the maturing of the industry we realized that it is really hard to compete with larger software houses. So we've gone one of two ways: we work for a proprietary software house for a reasonable wage (no one becomes millionaires, generally unless they are an Owner), either while being on contract or salary.
A large number of civilized programmers are actually giving away their code in the F/OSS community because that is what they like to do.
It just turns out that the reality today is you're probably going to just be paid for the "performance" or perhaps just with gratitude.
Get used to it... things change. Copyright attempts to artificially make information a marketable quantity. It no longer is and the Network is going to enforce its own laws. You'll just have to work for every buck like the rest of us.
> You cant write OS/Drivers in bytecodes
Forth? OpenBoot? The currently alive OpenBIOS project?
QED
There is no way to use exceptions that is generally readable. And rampant uncontrollable gotos, which is a significant aspect of exceptions isn't avoidable (please enlighten me otherwise).
And whether libraries generate exceptions instead of return codes isn't typically under your control. It's under the control of the creator of the library.
Any exception handler is going to be a nested block of code. and if you allow an outer exception handler to be reached you really have a totally unpredictable result as far as the curent state of the machine. You have no choice but to write ugly code if exceptions are around.
Add to that C#'s interminable nesting of classes generally, and you have code moving several levels deep to the right.
There's no way to make such code readable.
-- John.
Return codes are better than exceptions.
Exceptions are worse than gotos... at least you know when and where the goto is going to go...
Exceptions break normal program flow.
They are an unstoppable evil force and anyone that thinks otherwise is simply misinformed.
Also handling API's which normally generate "exceptions" (seem more like the rule than the exception...) makes every piece of code that uses the API look like a nested mess of spaghetti (hmmm... sort of like any given C# program...)
For serious CPU confusion hitting a low level exception handler makes sense... null pointer deref, divide by zero, invalid instruction...
But exceptions are an evil bane of modern languages and I can only hope they are a temporary fad.
Miguel-fez: C, goodday... I say goodday!
Well until those Martian leeches start contributing to CVS the distinction is probably irrelevant.
-- John.
Or singing lessons.
Keep in mind though with less shyness and actor friends he'll get figure out how to attract attention from females too early and never build up the solid hacking skills necessary to be a world class geek.
If that's what you want, fine... but you may be ruining him for his true calling.
Even the wise cannot see the end of all things...
> You missed the point. :-)
Well, this time you made some
>The customers don't give a shit. A smallish medical practice has something like $2 million in "sales" per year. $5-20k is pissing in the ocean.
Customers don't care about saving 20K in licensing fees? With each upgrade? I'll bet plenty of small practices do. Anyway, money is money.
>Doctors want their shit to work so the insurance companies pay for his services. That's it. They do not care about open source and likely prefer to deal with the vendors that they know about.
That's a good point: Doctors don't care about FOSS. What they do care about is getting a good product at a reasonable price, just like any business does. But I don't think FOSS implies crap. In fact, once it is stable the quality is typically high. I'm not buying the implied argument here that FOSS doesn't work.
>The other thing is that EDI and other standards that vertical applications must adhere to are not free. The standards and specs are not open and often cost signifigant sums of money.
Standards are not patents. You only have to pay once to get the standard, so buying all the standards necessary for a FOSS is possible. They could also be donated by third parties. Also there are typically publicly available drafts of standards leading up to the final standard which are public. These are normally sufficient for getting development 90% of the way along.
>You do not understand how vertical markets work at all.
Ah, disappointment... I was expecting you to disagree with me factually in some way...
Of course the existing vendors don't care about FOSS (other than to be afraid of it). Why should they? FOSS will disrupt their proprietary business model, as it is currently disrupting all proprietary software business models.
Yeah, FOSS software is how customers will be freed from being violated (to use your term) by license costs, although not support costs. There aren't going to be a bunch of developers giving out free support on IRC for this kind of specialty software. It ain't the fun stuff, that's for sure. As you say it's nothing complicated... that means boring work.
And well, it turns out that it is good for the doctor who can go to anybody for support. But if you've ever done any contracting you would know that once a customer has a vendor they trust who offers them a rate that fits their budget, they tend to stay with that vendor barring some cataclysm or bad service.
Think of it this way... FOSS gives the customer what they want... reasonable prices and no vendor lock-in. And it breaks the market wide open for anyone who wants to enter it since there are no complicated license deals/agreements. It's called "competition" and though the entrenched, established vendors would rather not have any, efforts like this seem to imply it is coming.
The first one is always free.
There is a lot of money in this niche market. Making a GPLd billing package would be the thin edge of the wedge to getting FOSS developers in the door.
FOSS developers don't work for nothing (some do). The ideal model is work for hire improving and releasing GPL'd source code. But yeah somewhere along the way in every FOSS project somebody has to give away the code to get the ball rolling. The code stays free but if an end user wants a custom change, they have to pay. The could pay the company who the bought the proprietary software to change their own system (big $$$'s since they have a monopoly on their own code), or they can go to the original developers of the GPL'd code, or even hire anyone else who is willing to learn the code base.
With FOSS development model it is true that we won't make megabucks off of royalty and license fees. But for the individual developer I think it has been that way for quite a while, anyway.