Given how IT staff get harassed to fix everything, and blamed for everything broken, I would suggest an idea floated during my days as a university student.
See, we had these "Programmers On Duty", or PODs, many of whom were volunteers, who would look at your program, and attempt to help you find what was wrong. This was pretty much a thankless job, and anything you broke, and they couldn't fix, was considered their fault. (This was the late 70s era of punched cards, and computer printouts, with actual terminals a rare and coveted tool -- the POD had an office with, you guessed it, a terminal -- a CRT to boot, so one would not have to keep trying to use the back of discarded printouts in the DECwriters. The attraction of POD duty was access to that terminal, in hopes it would be a slow day.)
A bunch of us thought that PODs should be issued distinctive uniforms as well: superhero-style costumes actually. Ostensibly this was to distinguish them as members of a rare breed: people who could debug programs quickly. In fact, the intent was to shield their identity lest the be pestered to provide help while off duty.
The problem isn't the lack of paid overtime. The salary reflects the job, and it rather all averages out... as long as you're responsible for your work, your mistakes, and the work and mistakes of any subordinates you might have.
Where this model breaks is when you become accountable for the mistakes of others who are not your subordinates, but your peers.
IOW, you think you can enjoy the long weekend, because your work is on track. But no! Doofus-peer screwed up really badly, and is too dumb to fix it by the Tuesday deadline, so you get to play hero... without remuneration. That part rather sucks. The worst part is you realize that if it isn't fixed, the company can suffer, and hence you will suffer, through no fault of your own. So, refusing is rather like cutting off your nose to spite your face.
Then there are shops where bugs are assigned to those who have demonstrated an ability to fix them quickly... and where any bug you fix is presumed to be a mistake YOU made, and therefore reflects badly on you come review time. A certain company in Redmond is notorious for this -- the skill greatest rewarded is not good work, or an ability to fix the mistakes of others, but the ability to deflect work to others.
I once worked in a place where, after a full day, had to pull an all-nighter to fix someone else's screw up. Well, the job was done, I left around noon, and got docked a half a day vacation for doing so.
Not all shops are like that, of course, and I'm quite pleased about where I work now. But, enough are that it's off-putting. Combine the presumption that the good will fix the work of the bad with incomes that attract the incompetent and management that often can't tell the difference, and it can be a recipe for a real sweatshop. The only solution is to keep one's eyes open for better employment in such circumstances.
The upside is that we get to do something we actually enjoy. The deterministic behavior of programmable electronics (becoming indeterministic only when events can't be sequenced to the necessary temporal resolution) draws those with rational minds. For those of us with a good theoretical background in the mathematics behind it (and often one or two degrees to back that up), architecture positions pay well. I've been in the biz since 1975 from the ripe old age of 14.
The downsides, however, are many:
1) Often management doesn't understand the subtle reasons behind a problem, or why a particular solution that is easy and obvious is completely "wrong" (or at least inconsistent with future requirements).
2) There is no paid overtime. Salaries generally compensate for this, and frankly professionals SHOULD be expected to fix their errors on their own time (and their own dime). However, that does not work well in environments where workers are fungible: doofus A messes up, and expert B is stuck cleaning up the mess, often in "crisis mode" on his own time. YMMV depending on the shop. Good people tend to leave bad shops, though.
3) Academic training has given way to "trade skills". I am appalled that many undergraduate programs focus on the IDE or bloated library of the day, instead of fundamental algorithms and classic processor architecture. Add to this the fact that many non-experts can't tell the difference between the skilled and the not so skilled.
Until the first hospitals for deliveries were set up the death rate for women in childbirth was around 16%.
I'd say those would be dicey odds for anyone delivering without emergency equipment or trained medical staff nearby,
Now, if a midwife was to have performed the delivery, this mother to be was likely deemed "low risk", so sampling bias will apply if we look at "home births where the midwife was late", but giving birth is not exactly risk-free.
The dilemma is that one might actually want to hear the band in question, or patronize the particular establishment, but the entertainment is just TOO DAMN LOUD.
I like loud music... in moderation, when I'm in the mood.
Yet, at the ripe old-farty age of 48 I find my hearing far more sensitive than that of my peers, and even my 16 year old daughter (who I'm forever admonishing to turn down the TV, music, etc. because it is TOO LOUD. She, OTOH complains she can't hear it, and risks a vicious circle of ever-louder music and hearing loss).
It's so bad that sometimes the sound in movie theaters is too loud for me.
The problem her is the background and skill set of "the next slob".
Do I include a treatise on the merits of sliding window protocols in an implementation of a TCP stack? It makes sense if "the next slob" know nothing about networking, but is smart enough to learn. Of course, the PHB will expect us to be "interchangeable" when this is clearly not true.
Or, do I dare presume that someone called upon to maintain network code will be happy with unsigned long wnd;/* sliding window */ in a structure as adequate documentation?
Often one does not even know the scope of a piece of code one is given, or what presumptions were made about "the next slob" by "last slob".
But. by far, the largest problem appears to be aggressive documentation to the level of the "lowest common denominator" expected to maintain something of the "trees" of a program, with little regard to the overall "forest" of them.
Clearly, the theater can request deletion of the parts of the movie that were recorded, but nothing else. Sounds like some frame by frame masking is in order.
I remember very clearly a tale of similar woe involving an amount of flesh to be cut, but no blood to be spilt.
Yes, but electrical stunning and subsequent shooting of a bolt through the head is not "cruel" or "unusual". That's how we "humanely" slaughter cattle.
Either the programmer does the "work" (tracking memory (languages without built-in run-time garbage collection), structure layouts (assembler programming)), or the machine does the work.
If the machine does the work once at compile time, there is no run-time overhead (think mapping structs and function arguments to memory offsets and stack frame offsets). If the machine generates code to do the work at run-time, there is run-time overhead (think virtual function delegation and base clase fixups, particularly with multiple inheritence).
Garbage collection involves run-time overhead of letting the machine track when something is no longer referenced, either because the programmer is too lazy, or can not know, or is prone to get it wrong: debugging the garbage collector is easier than debugging every program that manages memory, and that effort can be leveraged for all programs that use the garbage collector... at the expense of run-time overhead even when it is not necessary.
Smart compilers can help: pointers to dynamic memory that does not have references passed to objects or functions that affect internal state can be recognized and the related objects destroyed when the pointer leaves scope (think auto_ptr in a function). You pay the run-time garbage collection overhead only when it is "really necessary" for some value of "the compiler is not smart enough to tell".
Pointers take so many flavors, and unfortunately, most languages upcast them freely to the most general type (often losing the distinction between something allocated dynamically and not, and something that "someone else" has to handle the reclamation of... or not).
you have pointer to foo, pointer to foo on the stack, pointer to foo dynamically allocated, foo being the i't element of an array inside an object bar that is either on the stack, dynamically allocated, or static, etc. What to do when you no longer need to reference what your pointer refers to often depends on type information you either don't have, or can not be known. Operations on pointers therefore justifiably call for a virtual dispatch table... for those pointers where they may be of different flavors. And, then you have to be able to tell -- you don't always need the overhead (think of a pointer through an array that you walk and then no longer need).
I sense that language support for the various kinds of pointers is lacking, or where it is possible, upcasting to lose type information is too easy (Heck, C++ will let you take the address of anything, and wham! you've got a bald pointer. You can prevent this for specific types by overloading the address-of operator, but you can't prevent the programmer from defining a type that doesn't have an explicit one, or require all types to derive from a common base.
Well, I understand our anarchist friend's angst that rights are lost if not defended, but they are reciprocal: I don't own the public lands in my town, and it is reasonable that they be administered by elected representatives of the townsfolk and I should respect the rules related to their sharing... so long as they do not infringe rights I actually do have.
Just because I have the right to peaceful assembly does not mean others are obligated to provide me a place to do so.
Even fundamental rights, like speech, are not absolute. Prior restraint, though abused, is warranted, in narrow circumstances, when the speech would otherwise reasonably be expected to cause irreparable harm. You can shout "Fire!" in a crowded theater, but only if there is a fire there: surely a panic will ensue, but the risk of injury of trampling is less than certain death by fire. If there is no fire, such panic-inducing speech is harmful.
Private property yes. But it was also a "public place". Special laws generally apply in such circumstances: owners can ask people to leave (and they are trespassing if they don't), but the presumption is that the public are welcome.
We were not protesting and did not need a permit. But, there were reasonable bylaws regarding crowd control and we chose to follow them.
I suppose if we did have an issue to protest AND were obstructed from doing so, we could chose to engage in civil disobedience.
The bylaws in question were designed to try to ensure that assemblies remained peaceful and the dollar amounts involved were not overly burdensome.
The purpose of permits and insurance is mot to deter assembly (though they can be abused for those ends), but rather to ensure order and protect property.
I once helped organize a peaceful public march on public sidewalks that ended in a public park with a community picnic. I had to obtain indemnity forms from all participants for my own protection (in case someone slipped and twisted an ankle), but more imnportantly, also obtain insurance to compensate the city if there was any damage: $250,000 worth, given the size of the crowd. (It was actually cheap, about $200).
I was also expected to ensure that people acted in an ORDERLY manner, and would have been required to pay for police presence if the crowd was expected to be large.
The point here was that the event was badly organized and the organizers charged regardless of whether they cooperated with "tweeting" or not. They just made a bad situation worse by not cooperating.
Seriously, though, the Peace Prize is very political, and it would take a HUGE outcry of global public support for Linus or Richard to get any lip service.
The Peace Prize is often awarded to those who end disputes, perhaps the very same people who started them in the first place
If anything, ubiquitous computing is not a stabilizing force but a disruptive one, empowering people against governments by way of improving the exchange of information, and encouraging association. Think "flash mob". This may be a force toward renewed justice, but the process can be anything but peaceful.
"Compared to glass, ETFE film is 1% the weight, transmits more light and costs 24% to 70% less to install. It's also resilient (able to bear 400 times its own weight, self-cleaning (due to its nonstick surface) and recyclable. On the other hand it is prone to punctures by sharp edges, therefore it is mostly used for roofs.[1] In sheet form as commonly employed for architecture, it is able to stretch to three times its length without loss of elasticity. Employing heat welding, tears can be repaired with a patch or multiple sheets assembled into larger panels.
ETFE has an approximate tensile strength of 42 N/mm (6100 psi), with a working temperature range of 89 K to 423 K (-185 C to 150 C or -300 F to 300 F)"
So far so good... but, what's this...:
"Combustion of ETFE occurs in the same way as a number of other fluoropolymers, in terms of releasing hydrofluoric acid (HF). HF is extremely corrosive, and so appropriate caution must be exercised."
Libertarianism certainly allows for FLOSS (Free/Libre Open Source Software, as I think even RMS calls it these days), in the sense that it does not prohibit either altruism (giving something away), or cooperation (working together).
However, to argue, as RMS does, that non-free software is somehow "immoral", IS anti-libertarian, because libertarians certainly do not prohibit the existence of proprietary software -- many, of the Open Source camp do think it is a bad deal, however.
Now, to effectively compete against proprietary software, when marketed to the masses, FLOSS likely requires advertising and marketing-"spin" around it, if for no other reason than to combat the competition's advertising and FUD. And, this has to be funded somehow, leading to the "support model" of funding FLOSS development.
One either has to reduce one's costs (by developing a program that simplifies some aspect of their life which they might wish to share), or earn revenue (by selling something around something one otherwise gives away), or what one does is unsustainable. A widely popular FLOSS program will die on the vine if the bandwidth costs of it's distribution can not be paid SOMEHOW (donations, becoming part of a larger project, hosted on a site that absorbs these costs (e.g. Sourceforge), etc.
Now, for those of us who have the skills to take, and improve FLOSS, the overhead of advertising and marketing are unnecessary: we know a good thing when we see it. But, programmers, and good programmers in particular, are a rare breed.
I often wonder if the aggregation mechanism that permits FLOSS and Proprietary software to work together (distributed together, but running together only in the most tenuous of relationships) isn't serendipitous: Non-free drivers that permit free applications, while a potentially dangerous trap, at least get those applications USED, and thus NOTICED. It's a form of "free advertising" for the app. It creates an incentive to replace the non-free parts when the app becomes popular. Similarly, "less free" (LGPL) code gets noticed because of all the proprietary apps that can use it. BSD licenses take this to a further degree in that non-free forks of otherwise free code are permitted.
So we get the SUSE vs. GNU/Linux vs. Debian vs. Ubuntu vs. BSD wars where the differences are often ideological.
As a libertarian, I see this choice as HEALTHY for the marketplace of FLOSS, and how it works with, and against, proprietary code, to the benefit of both.
I doubt very much if FLOSS would flourish like it does if copyright law permitted RMS to include anti-aggregation clauses in the GPL, even as he opposes ALL non-free software.
Proprietary software is dangerous, and arguably anti-social, but this does not mean it is not occasionally useful until something better comes along. I wonder how many programmers are paid well enough to produce proprietary code so that they can devote some of their leisure time toward producing FLOSS code. I have produced proprietary code for use in embedded devices (arguably not useful to have free) for decades, and now spend much of my time aggregating FLOSS code, with proper license deference, with much smaller amounts of proprietary code in far more complex embedded devices (where the argument of user control is far more compelling). I could not do this if proprietary code were, as RMS might wish, illegal. I take the libertarian stance that "Let the user chose to accept the license, or not," so long as the choice is an informed one.
How do you tie the gift/loyalty card to a registered user? I can understand the card authenticating a user to your gateway, but how does it match a particular PC to that user? username/password on the card, which the user uses to get their three hours (authenticated by your swipe)? Or just a unique serial number on the card which they enter as part of authentication?
I'm getting the feeling that much of your custom work could be accomodated by existing hotspot software and the only "glue" would be getting the register to talk to the gateway.
If you use code under Linux to handle that, and the router runs Linux, and the footprint is small...
Of course, I'm just speculating here, but it might be worth considering if you could reduce your code to a small piece to port to Linux with all the OpenWRT "networking bits" already there.
Does it have to support your custom code? is it sufficient to gate access fo three hours? I think there might be hotspot packages that run under OpenWRT which might do the trick for you. (Captive HTTP splash/registration page, captive DNS until registered, etc.)
If OpenWRT would work, look at a Linksys WRT54GL. About as cheap as it gets.
You get three four ethernet LAN ports, wireless, and WAN port.
You'd think the four LAN ports would be bridged, and you'd be right, but the unit and OpenWRT support VLAN tagging to keep them on separate nets if you want.
Well, yes, but as a chemist would say, the activation energy was a bit of a bitch to overcome.
More to the point, much of the complience burden had to be foisted on departments other than Engineering.
Using GPL code helped us meet our price and market entry goals, yes, but it messed with the budget of Manufacturing, and because of the contractor issue, HR: "Why, exacly, can't they use their own computers?
GPL complience isn't an engineering issue, it's a corporate issue. Any time your plan to save money involves costing another department money, even as a "one off" to get process in place, and even if the net effect is beneficial, you have a major hurdle to overcome.
Slashdot Mirror
Given how IT staff get harassed to fix everything, and blamed for everything broken, I would suggest an idea floated during my days as a university student.
See, we had these "Programmers On Duty", or PODs, many of whom were volunteers, who would look at your program, and attempt to help you find what was wrong. This was pretty much a thankless job, and anything you broke, and they couldn't fix, was considered their fault. (This was the late 70s era of punched cards, and computer printouts, with actual terminals a rare and coveted tool -- the POD had an office with, you guessed it, a terminal -- a CRT to boot, so one would not have to keep trying to use the back of discarded printouts in the DECwriters. The attraction of POD duty was access to that terminal, in hopes it would be a slow day.)
A bunch of us thought that PODs should be issued distinctive uniforms as well: superhero-style costumes actually. Ostensibly this was to distinguish them as members of a rare breed: people who could debug programs quickly. In fact, the intent was to shield their identity lest the be pestered to provide help while off duty.
The problem isn't the lack of paid overtime. The salary reflects the job, and it rather all averages out... as long as you're responsible for your work, your mistakes, and the work and mistakes of any subordinates you might have.
Where this model breaks is when you become accountable for the mistakes of others who are not your subordinates, but your peers.
IOW, you think you can enjoy the long weekend, because your work is on track. But no! Doofus-peer screwed up really badly, and is too dumb to fix it by the Tuesday deadline, so you get to play hero... without remuneration. That part rather sucks. The worst part is you realize that if it isn't fixed, the company can suffer, and hence you will suffer, through no fault of your own. So, refusing is rather like cutting off your nose to spite your face.
Then there are shops where bugs are assigned to those who have demonstrated an ability to fix them quickly... and where any bug you fix is presumed to be a mistake YOU made, and therefore reflects badly on you come review time. A certain company in Redmond is notorious for this -- the skill greatest rewarded is not good work, or an ability to fix the mistakes of others, but the ability to deflect work to others.
I once worked in a place where, after a full day, had to pull an all-nighter to fix someone else's screw up. Well, the job was done, I left around noon, and got docked a half a day vacation for doing so.
Not all shops are like that, of course, and I'm quite pleased about where I work now. But, enough are that it's off-putting. Combine the presumption that the good will fix the work of the bad with incomes that attract the incompetent and management that often can't tell the difference, and it can be a recipe for a real sweatshop. The only solution is to keep one's eyes open for better employment in such circumstances.
The upside is that we get to do something we actually enjoy. The deterministic behavior of programmable electronics (becoming indeterministic only when events can't be sequenced to the necessary temporal resolution) draws those with rational minds. For those of us with a good theoretical background in the mathematics behind it (and often one or two degrees to back that up), architecture positions pay well. I've been in the biz since 1975 from the ripe old age of 14.
The downsides, however, are many:
1) Often management doesn't understand the subtle reasons behind a problem, or why a particular solution that is easy and obvious is completely "wrong" (or at least inconsistent with future requirements).
2) There is no paid overtime. Salaries generally compensate for this, and frankly professionals SHOULD be expected to fix their errors on their own time (and their own dime). However, that does not work well in environments where workers are fungible: doofus A messes up, and expert B is stuck cleaning up the mess, often in "crisis mode" on his own time. YMMV depending on the shop. Good people tend to leave bad shops, though.
3) Academic training has given way to "trade skills". I am appalled that many undergraduate programs focus on the IDE or bloated library of the day, instead of fundamental algorithms and classic processor architecture. Add to this the fact that many non-experts can't tell the difference between the skilled and the not so skilled.
Still, I wouldn't do anything different.
Until the first hospitals for deliveries were set up the death rate for women in childbirth was around 16%.
I'd say those would be dicey odds for anyone delivering without emergency equipment or trained medical staff nearby,
Now, if a midwife was to have performed the delivery, this mother to be was likely deemed "low risk", so sampling bias will apply if we look at "home births where the midwife was late", but giving birth is not exactly risk-free.
The dilemma is that one might actually want to hear the band in question, or patronize the particular establishment, but the entertainment is just TOO DAMN LOUD.
I like loud music... in moderation, when I'm in the mood.
Yet, at the ripe old-farty age of 48 I find my hearing far more sensitive than that of my peers, and even my 16 year old daughter (who I'm forever admonishing to turn down the TV, music, etc. because it is TOO LOUD. She, OTOH complains she can't hear it, and risks a vicious circle of ever-louder music and hearing loss).
It's so bad that sometimes the sound in movie theaters is too loud for me.
The problem her is the background and skill set of "the next slob".
Do I include a treatise on the merits of sliding window protocols in an implementation of a TCP stack? It makes sense if "the next slob" know nothing about networking, but is smart enough to learn. Of course, the PHB will expect us to be "interchangeable" when this is clearly not true.
Or, do I dare presume that someone called upon to maintain network code will be happy with unsigned long wnd; /* sliding window */ in a structure as adequate documentation?
Often one does not even know the scope of a piece of code one is given, or what presumptions were made about "the next slob" by "last slob".
But. by far, the largest problem appears to be aggressive documentation to the level of the "lowest common denominator" expected to maintain something of the "trees" of a program, with little regard to the overall "forest" of them.
Clearly, the theater can request deletion of the parts of the movie that were recorded, but nothing else. Sounds like some frame by frame masking is in order.
I remember very clearly a tale of similar woe involving an amount of flesh to be cut, but no blood to be spilt.
Why yes, anything to distract from that film would have made that part the best three minutes of the movie.
My daughter owes me big time for seeing it with her.
Yes, but electrical stunning and subsequent shooting of a bolt through the head is not "cruel" or "unusual". That's how we "humanely" slaughter cattle.
So, I think there's a lot of "wiggle room".
True dat. My daughter dragged me to see it.
'Course I dragged her to see 2012 (WHICH I WANTED TO SEE BECAUSE OF THE SPOOFED TRAILER), so I suppose we are even.
Yay, spaceships?
Yay, Spaceships! (except they weren't)
Either the programmer does the "work" (tracking memory (languages without built-in run-time garbage collection), structure layouts (assembler programming)), or the machine does the work.
If the machine does the work once at compile time, there is no run-time overhead (think mapping structs and function arguments to memory offsets and stack frame offsets). If the machine generates code to do the work at run-time, there is run-time overhead (think virtual function delegation and base clase fixups, particularly with multiple inheritence).
Garbage collection involves run-time overhead of letting the machine track when something is no longer referenced, either because the programmer is too lazy, or can not know, or is prone to get it wrong: debugging the garbage collector is easier than debugging every program that manages memory, and that effort can be leveraged for all programs that use the garbage collector... at the expense of run-time overhead even when it is not necessary.
Smart compilers can help: pointers to dynamic memory that does not have references passed to objects or functions that affect internal state can be recognized and the related objects destroyed when the pointer leaves scope (think auto_ptr in a function). You pay the run-time garbage collection overhead only when it is "really necessary" for some value of "the compiler is not smart enough to tell".
Pointers take so many flavors, and unfortunately, most languages upcast them freely to the most general type (often losing the distinction between something allocated dynamically and not, and something that "someone else" has to handle the reclamation of... or not).
you have pointer to foo, pointer to foo on the stack, pointer to foo dynamically allocated, foo being the i't element of an array inside an object bar that is either on the stack, dynamically allocated, or static, etc. What to do when you no longer need to reference what your pointer refers to often depends on type information you either don't have, or can not be known. Operations on pointers therefore justifiably call for a virtual dispatch table... for those pointers where they may be of different flavors. And, then you have to be able to tell -- you don't always need the overhead (think of a pointer through an array that you walk and then no longer need).
I sense that language support for the various kinds of pointers is lacking, or where it is possible, upcasting to lose type information is too easy (Heck, C++ will let you take the address of anything, and wham! you've got a bald pointer. You can prevent this for specific types by overloading the address-of operator, but you can't prevent the programmer from defining a type that doesn't have an explicit one, or require all types to derive from a common base.
Well, I understand our anarchist friend's angst that rights are lost if not defended, but they are reciprocal: I don't own the public lands in my town, and it is reasonable that they be administered by elected representatives of the townsfolk and I should respect the rules related to their sharing... so long as they do not infringe rights I actually do have.
Just because I have the right to peaceful assembly does not mean others are obligated to provide me a place to do so.
Even fundamental rights, like speech, are not absolute. Prior restraint, though abused, is warranted, in narrow circumstances, when the speech would otherwise reasonably be expected to cause irreparable harm. You can shout "Fire!" in a crowded theater, but only if there is a fire there: surely a panic will ensue, but the risk of injury of trampling is less than certain death by fire. If there is no fire, such panic-inducing speech is harmful.
Private property yes. But it was also a "public place". Special laws generally apply in such circumstances: owners can ask people to leave (and they are trespassing if they don't), but the presumption is that the public are welcome.
We were not protesting and did not need a permit. But, there were reasonable bylaws regarding crowd control and we chose to follow them.
I suppose if we did have an issue to protest AND were obstructed from doing so, we could chose to engage in civil disobedience.
The bylaws in question were designed to try to ensure that assemblies remained peaceful and the dollar amounts involved were not overly burdensome.
The purpose of permits and insurance is mot to deter assembly (though they can be abused for those ends), but rather to ensure order and protect property.
I Agree.
I once helped organize a peaceful public march on public sidewalks that ended in a public park with a community picnic. I had to obtain indemnity forms from all participants for my own protection (in case someone slipped and twisted an ankle), but more imnportantly, also obtain insurance to compensate the city if there was any damage: $250,000 worth, given the size of the crowd. (It was actually cheap, about $200).
I was also expected to ensure that people acted in an ORDERLY manner, and would have been required to pay for police presence if the crowd was expected to be large.
The point here was that the event was badly organized and the organizers charged regardless of whether they cooperated with "tweeting" or not. They just made a bad situation worse by not cooperating.
... just saying.
Seriously, though, the Peace Prize is very political, and it would take a HUGE outcry of global public support for Linus or Richard to get any lip service.
The Peace Prize is often awarded to those who end disputes, perhaps the very same people who started them in the first place
If anything, ubiquitous computing is not a stabilizing force but a disruptive one, empowering people against governments by way of improving the exchange of information, and encouraging association. Think "flash mob". This may be a force toward renewed justice, but the process can be anything but peaceful.
Wikipedia states:
"Compared to glass, ETFE film is 1% the weight, transmits more light and costs 24% to 70% less to install. It's also resilient (able to bear 400 times its own weight, self-cleaning (due to its nonstick surface) and recyclable. On the other hand it is prone to punctures by sharp edges, therefore it is mostly used for roofs.[1] In sheet form as commonly employed for architecture, it is able to stretch to three times its length without loss of elasticity. Employing heat welding, tears can be repaired with a patch or multiple sheets assembled into larger panels.
ETFE has an approximate tensile strength of 42 N/mm (6100 psi), with a working temperature range of 89 K to 423 K (-185 C to 150 C or -300 F to 300 F)"
So far so good... but, what's this...:
"Combustion of ETFE occurs in the same way as a number of other fluoropolymers, in terms of releasing hydrofluoric acid (HF). HF is extremely corrosive, and so appropriate caution must be exercised."
Hmm....
Perhaps some of these people actually performed physically strenuous work for a living and achieved the holy grail of trading fat for muscle.
BMI is part of the picture. You really have to look at body fat percentage. (Hint: body builders have horrible BMIs: their muscle is presumed as fat!)
Newbies to exercise can actually "lose weight" and "gain muscle" at the same time (because they have so little to begin with).
When you send ME email, it winds up in MY computer, not one owned by an ISP.
And, even if an ISP held it "in trust" for me, so what?
Finally, the roads are public spaces, but the USPS, UPS and Fedex trucks on them are not.
What was this judge smoking?
Libertarianism certainly allows for FLOSS (Free/Libre Open Source Software, as I think even RMS calls it these days), in the sense that it does not prohibit either altruism (giving something away), or cooperation (working together).
However, to argue, as RMS does, that non-free software is somehow "immoral", IS anti-libertarian, because libertarians certainly do not prohibit the existence of proprietary software -- many, of the Open Source camp do think it is a bad deal, however.
Now, to effectively compete against proprietary software, when marketed to the masses, FLOSS likely requires advertising and marketing-"spin" around it, if for no other reason than to combat the competition's advertising and FUD. And, this has to be funded somehow, leading to the "support model" of funding FLOSS development.
One either has to reduce one's costs (by developing a program that simplifies some aspect of their life which they might wish to share), or earn revenue (by selling something around something one otherwise gives away), or what one does is unsustainable. A widely popular FLOSS program will die on the vine if the bandwidth costs of it's distribution can not be paid SOMEHOW (donations, becoming part of a larger project, hosted on a site that absorbs these costs (e.g. Sourceforge), etc.
Now, for those of us who have the skills to take, and improve FLOSS, the overhead of advertising and marketing are unnecessary: we know a good thing when we see it. But, programmers, and good programmers in particular, are a rare breed.
I often wonder if the aggregation mechanism that permits FLOSS and Proprietary software to work together (distributed together, but running together only in the most tenuous of relationships) isn't serendipitous: Non-free drivers that permit free applications, while a potentially dangerous trap, at least get those applications USED, and thus NOTICED. It's a form of "free advertising" for the app. It creates an incentive to replace the non-free parts when the app becomes popular. Similarly, "less free" (LGPL) code gets noticed because of all the proprietary apps that can use it. BSD licenses take this to a further degree in that non-free forks of otherwise free code are permitted.
So we get the SUSE vs. GNU/Linux vs. Debian vs. Ubuntu vs. BSD wars where the differences are often ideological.
As a libertarian, I see this choice as HEALTHY for the marketplace of FLOSS, and how it works with, and against, proprietary code, to the benefit of both.
I doubt very much if FLOSS would flourish like it does if copyright law permitted RMS to include anti-aggregation clauses in the GPL, even as he opposes ALL non-free software.
Proprietary software is dangerous, and arguably anti-social, but this does not mean it is not occasionally useful until something better comes along. I wonder how many programmers are paid well enough to produce proprietary code so that they can devote some of their leisure time toward producing FLOSS code. I have produced proprietary code for use in embedded devices (arguably not useful to have free) for decades, and now spend much of my time aggregating FLOSS code, with proper license deference, with much smaller amounts of proprietary code in far more complex embedded devices (where the argument of user control is far more compelling). I could not do this if proprietary code were, as RMS might wish, illegal. I take the libertarian stance that "Let the user chose to accept the license, or not," so long as the choice is an informed one.
"That's IT?!"
"Well, it's a large galaxy, and there's not a lot of space in the book."
Really, someone should start a HHGTTG-pedia based on HHGTTG canon, and WikiPedia standards for alternate content.
How do you tie the gift/loyalty card to a registered user? I can understand the card authenticating a user to your gateway, but how does it match a particular PC to that user? username/password on the card, which the user uses to get their three hours (authenticated by your swipe)? Or just a unique serial number on the card which they enter as part of authentication?
I'm getting the feeling that much of your custom work could be accomodated by existing hotspot software and the only "glue" would be getting the register to talk to the gateway.
If you use code under Linux to handle that, and the router runs Linux, and the footprint is small...
Of course, I'm just speculating here, but it might be worth considering if you could reduce your code to a small piece to port to Linux with all the OpenWRT "networking bits" already there.
Does it have to support your custom code? is it sufficient to gate access fo three hours? I think there might be hotspot packages that run under OpenWRT which might do the trick for you. (Captive HTTP splash/registration page, captive DNS until registered, etc.)
If OpenWRT would work, look at a Linksys WRT54GL. About as cheap as it gets.
You get three four ethernet LAN ports, wireless, and WAN port.
You'd think the four LAN ports would be bridged, and you'd be right, but the unit and OpenWRT support VLAN tagging to keep them on separate nets if you want.
... but why'd they have to ruin it with all that Microsoft stuff?
Well, yes, but as a chemist would say, the activation energy was a bit of a bitch to overcome.
More to the point, much of the complience burden had to be foisted on departments other than Engineering.
Using GPL code helped us meet our price and market entry goals, yes, but it messed with the budget of Manufacturing, and because of the contractor issue, HR: "Why, exacly, can't they use their own computers?
GPL complience isn't an engineering issue, it's a corporate issue. Any time your plan to save money involves costing another department money, even as a "one off" to get process in place, and even if the net effect is beneficial, you have a major hurdle to overcome.