While it had been done before, and will probably be done better (or worse), the Java software based sandbox security made a whole class of applications feasible, and enabled a new level of fault isolation for non-malicious software. *nix process based security and its predecessors were ground breaking. Java applies that within a shared address space at the ClassLoader level.
Our proprietary accounting software was built from the get go on open source OSes (starting with IBM EDX - obscure, but open source - though not in the GPL sense). Originally written for a green screen environment, it was abandoned for prettier Windows bases systems by a few clients. All the companies that left functional for pretty either went under or came back. We now have a pretty web front end, and a growing number of EDI, Web Service, and Java interfaces to integrate with other software - even Windows software integrates via SOAP (when there is source available for a Windows programmer to customize).
As far as highly functional open source enterprise accounting software goes, have you looked at Adempiere? I have been playing with it, and it is good enough that my long term goal is to migrate our stuff to its framework.
"PC filtering software" is not very flexible at all. It ties you to a monopoly OS, and doesn't support filtering gateways (HTTP proxies). Ideally, users should be able to customized the approved list by adding/deleting entries. I would suggest publishing the approved list via secure DNS.
would be a positive filter. Instead of trying to filter the entire internet for everyone, create a Government Certified Safe Internet that lists web sites deemed "appropriate for children" by a new bureaucracy, and make it available to anyone's private filter on a voluntary basis. Require all government internet terminals available to children (e.g. libraries) to subscribe to the filter. Yes, there are already private companies that offer this service, but the constituents driving this evidently trust a giant government bureaucracy more than they trust a somewhat smaller corporate bureaucracy.
There will still be a market for private filter companies because they can offer different censoring standards to parents. It could actually be a good thing to have a voluntary censoring standard backed by general consensus. Private filters could start with the government database as a baseline, then add sites that "really should have been approved" or subtract sites that "my kid(s) can't handle". (For instance, my daughter had nightmares about "ducks biting her" after an incident involving a goose. She was not allowed to view "Jurassic Park" until she was much older, even though it was appropriate for the other kids.)
a digital camera with the lens cap on. Especially, if you can get the raw pixels, it contains a large component of true quantum randomness. Just run the bits into PRNGD (which runs the bits through a secure hash and adjusts the input/output bit rates according to the estimated randomness of the sources) with a conservative estimate of the percentage of quantum randomness.
"Some" drugs is right. Here in the eastern US, our streets are lined with mulberry trees (the unripe berries of which are hallucinogenic). And our government does nothing about it!
It's all about the time scale. Cox, for instance, on my $50/mo plan, offers peak bandwidth of 20Mbit/sec (so that picking up an MP3 from Amazon is nearly instantaneous), sustained average bandwidth of 5Mbit/sec (time scale unspecified, but my observations suggest it is 1 minute), and monthly average bandwidth of 40GB/month. They threaten to terminate you if you go over the monthly cap - which is dumb. They should do something like TW and either charge you or lower your peak.
So perhaps the term you are looking for is "average bandwidth" for some time period the average is taken over.
While the pricing seems a little high, I am *glad* that Time Warner is coming clean about the limitations of their service. A little competition will fix the pricing real quick.
Rather than automatically charge you more, some ISPs simply lower your peak bandwidth to ISDN levels - so that you still have (slow) internet access, and then offer to upgrade your monthly average for more dough. The peak bandwidth is restored as soon as the monthly average goes below the cap again.
I also think the "unlimited" advertising is a truth in advertising issue - and any company that advertises "unlimited" and then starts throttling you when you use "too much" should be prosecuted by the government for false advertising.
The only ancient culture I've read about that thought the earth was flat is early Babylon. Any people that either had ships on a large body of water, or were in contact with people that had ships on a large body of water, knew that the earth was round. You can't see a ship disappearing over the horizon and miss the implication.
As to Socrates, the Greeks even calculated the size of the earth pretty accurately.
I not only run this at home, but at lots of small business customers. Has 3Ghz Pentium D (dual core, 64-bit). Get 2 large SATA drives (500G or more) and 2G or more ECC memory. Starting price is $400, but by the time you get the memory and disk upgraded, it is about $600, $800 with onsite maintenance. A big benefit for me for home use was it is *quiet*. It has a single large (and therefore quiet) fan with ducting to draw air over the CPU heatsink. Look for it in the "small business section" of Dell.
Drawbacks: only 2 drive bays (upgrade to 840 for 4 bays - not as quiet). No sensors - at least that lm_sensors knows about. I just monitor the disk temperature.
Configuration: run the 2 drives with software RAID1, and LVM on top of that. Create a small (100M) RAID1 boot partition at the beginning of the disk. The RedHat/Fedora installer can create this configuration. (I also save and mirror the Dell diagnostics partition, and add it to the grub boot menu.)
How about the part where he isn't accused of any actual crime, just "possession of a weapon". Sure, NY probably has some left wing "gun control" law, but "possession of a weapon" is a constitutionally protected right, not a crime in my book.
Like with everything else, there is an optimum level of employment that supports open pro bono open source activity. Note that producing open source can itself be a paid job - especially as a freelancer with the right clients. If Stallman had his way, *all* paid programming work would be on GPL software. Two years ago, it looked like my company might go under, and I was doing a lot more pro bono on the side. Now there is tons of work, and it is hard to squeeze in even a simple Fedora packaging project. On the other hand, I wouldn't be contributing much as a homeless person either.
As a citizen, I don't really care whether my gov (US) uses Microsoft, Mac, Solaris, Linux, or AmigaOS. I *do* care when they publish documents I need to work with in an undocumented proprietary format. And no, OOXML doesn't fix that (it only pretends to). Yes, I can get by with Open Office DOC importer for the time being.
I didn't find it on Google, but about 30 years ago I read an account of a creature like a giant sand dollar that was dislodged from the deep ocean by an undersea earthquake. I can't verify it until I find a reference, but I recall that the scientist examining it found that it was largely silicon, hydrogen, and sulphur (and decayed rapidly giving off H2S). His theory was that it was silicon based life - and that its chemistry required deep ocean temperature and pressure to remain stable. (Note that there are carbon based ocean creatures able to process silicon to create SiO2 structures.)
Your example illustrates localtime() behavior, *not* time() behavior. If you use a timezone that includes leapseconds, then: $ export TZ=right/US/Eastern; date -d@1230768022; date -d@1230768023; date -d@1230768024 Wed Dec 31 18:59:59 EST 2008 Wed Dec 31 18:59:60 EST 2008 Wed Dec 31 19:00:00 EST 2008
Ya'll keep talking about localtime/mktime, when *I'm* talking 'bout time().
Yes, but we are not talking about mktime (kernel or libc) or localtime. We are talking about time(). If the intent of Posix is that particular time() values convert to particular localtimes() when using posix timezones, then linux is compliant. If you want the correct time of day, you use the "right" timezones - assuming you want the "correct" time of day to include leapseconds. Some systems apparently keep the correct time of day by slowing the time() clock for leapseconds. Doing this means time() is *not* the number of seconds since the epoch, but a smaller number.
To be posix compatible, you have to remove the leap seconds, creating aliased timestamps where the same value of time() refers to different seconds. By not having all that crap in there, and just counting seconds since the epoch, it is sane, simple, and non posix compatible.
However, it is easy to convert the sane result of time() to a posix result with a leap second table. And if I were delivering a posix compatible system, I would do that conditionally so that posix apps (assuming there are any that actually rely on time()%60 == seconds_in_minute) would work.
It is impossible to go the other direction, since the posix time is ambiguous.
Another interpretation could be that posix actually expects time() to be a simple count of seconds, but that the output of *localtime* should guarantee that time()%60 == seconds_in_minute. This would be a constraint on what timezones are allowed in a posix system. In fact, the more I think about it, I think this is what POSIX people really mean. You must use timezone files that do not handle leapseconds. So by not including leap seconds in the default timezones, linux is posix compatible. Only by using the timezone in the "right" directory do you get leapseconds, and are no longer compatible with posix - but time() still returns the same value. It is just the interpretation by localtime() that changes.
This is what I said at first, and what the linux man page implies.
Civil time is "baroque" but usable - every instant has a name, however complex the naming convention. Posix time is "broke" - it can't name every instant. Sane unix systems use a simple second count, which is both simple and usable, and can be converted to posix time when needed (hopefully never).
Civil time represents positive leap seconds as second 60: 23:59:59 23:59:60 00:00:00 00:00:01
DST is disambiguated by the Timezone name: November 2, 2008 1:00:01 AM EST is an hour later than November 2, 2008 1:00:01 AM EDT.
You are right about the posix definition. But the posix definition is stupid and useless, because it can't unambiguously represent a timestamp - so it is ignored or reinterpreted by sane unix implementations. You can convert a sane clock (like the traditional second count) to posix time (or even most insane localtime based clocks), but not vice versa. So if anyone actually has to run a posix compatible application that is actually braindead enough to rely on time()%60 == seconds_in_minute, then they can set an environment to convert the output of time().
The linux man page for time() mentions the posix definition, and then says they made a mistake - and they really meant seconds since the epoch.
It doesn't matter how NTP protocol represents time - as long as it can be unambiguously converted to system time (i.e. just about anything except posix time could be used). The leap second flag *is* a little weird, but is just a wrinkle when converting to system time.
I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).
NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as
the number of seconds between a specified time and the Epoch, according
to a formula for conversion from UTC equivalent to conversion on the
naive basis that leap seconds are ignored and all years divisible by 4
are leap years. This value is not the same as the actual number of
seconds between the time and the Epoch, because of leap seconds and
because clocks are not required to be synchronised to a standard refer-
ence. The intention is that the interpretation of seconds since the
Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further
rationale.
Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?
A posix timestamp isn't even an unambiguous time reference. I can deal with discontinuities (just convert to linear time), but the end result of POSIX is utterly and totally useless (can't be unambiguously converted to linear time). For crying out loud, keeping system time as a well defined MDYHMS would be more usable than posix time - at least you can convert to something more manageable.
IMO, everyone should just ignore POSIX time. A Unix timestamp is a plain second count - regardless of the humped monstrosity decreed by POSIX. This can be easily converted to posix time , UTC, GMT, localtime, or any other desired scheme. Posix time can't. It is a non-starter.
Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation.
The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:
$ TZ="right/US/Eastern" date; TZ="US/Eastern" date Sun Feb 8 17:52:42 EST 2009 Sun Feb 8 17:53:06 EST 2009
The take home salary is *not* the significant cost of hiring an American worker. You have FICA, Medicare, Unemployment insurance, Workers comp, plus lots more nickle and dime costs. Let me illustrate the end result with an example from a country even worse (in this respect - of course it is a nice place in other ways): Brazil.
Brazil got a socialist government that tried to end worker exploitation by decreeing a litany of benefits for all workers. Mandatory unemployment insurance, health care, maximum weekly hours, minimum wage, you name it. If you land a legal job in Brazil, you are really well taken care of - and you even get some spending money. The problem? Very few companies can afford to hire workers following all the rules. So instead, they offer jobs "under the table". You work for us, while officially unemployed, and we'll slip you money under the table. No benefits. No guarantees. This is what most workers in Brazil end up with. The end result is the opposite of the good intentions.
A friend was a lawyer in Brazil working for a non-profit that sued companies that failed to follow all the employment rules. The catch? His law firm hired *their* workers "under the table" with no benefits - they could not afford official workers as a non-profit.
A colleague of mine provided a "translation" of HP BASIC for april fools one year (35 years ago - HP2000). PRINT became SCRIBBLE, IF became SHOULD, GOTO became LEAP, LET became MAKE
10 I = 0 20 SHOULD I = 10 LEAP 50 30 SCRIBBLE I 35 MAKE I = I + 1 40 LEAP 20
Interestingly, no one had any trouble with their assignments (programs were stored tokenized, so you saw the new keywords in the "editor").
Slashdot Mirror
While it had been done before, and will probably be done better (or worse), the Java software based sandbox security made a whole class of applications feasible, and enabled a new level of fault isolation for non-malicious software. *nix process based security and its predecessors were ground breaking. Java applies that within a shared address space at the ClassLoader level.
Our proprietary accounting software was built from the get go on open source OSes (starting with IBM EDX - obscure, but open source - though not in the GPL sense). Originally written for a green screen environment, it was abandoned for prettier Windows bases systems by a few clients. All the companies that left functional for pretty either went under or came back. We now have a pretty web front end, and a growing number of EDI, Web Service, and Java interfaces to integrate with other software - even Windows software integrates via SOAP (when there is source available for a Windows programmer to customize).
As far as highly functional open source enterprise accounting software goes, have you looked at Adempiere? I have been playing with it, and it is good enough that my long term goal is to migrate our stuff to its framework.
"PC filtering software" is not very flexible at all. It ties you to a monopoly OS, and doesn't support filtering gateways (HTTP proxies). Ideally, users should be able to customized the approved list by adding/deleting entries. I would suggest publishing the approved list via secure DNS.
would be a positive filter. Instead of trying to filter the entire internet for everyone, create a Government Certified Safe Internet that lists web sites deemed "appropriate for children" by a new bureaucracy, and make it available to anyone's private filter on a voluntary basis. Require all government internet terminals available to children (e.g. libraries) to subscribe to the filter. Yes, there are already private companies that offer this service, but the constituents driving this evidently trust a giant government bureaucracy more than they trust a somewhat smaller corporate bureaucracy.
There will still be a market for private filter companies because they can offer different censoring standards to parents. It could actually be a good thing to have a voluntary censoring standard backed by general consensus. Private filters could start with the government database as a baseline, then add sites that "really should have been approved" or subtract sites that "my kid(s) can't handle". (For instance, my daughter had nightmares about "ducks biting her" after an incident involving a goose. She was not allowed to view "Jurassic Park" until she was much older, even though it was appropriate for the other kids.)
a digital camera with the lens cap on. Especially, if you can get the raw pixels, it contains a large component of true quantum randomness. Just run the bits into PRNGD (which runs the bits through a secure hash and adjusts the input/output bit rates according to the estimated randomness of the sources) with a conservative estimate of the percentage of quantum randomness.
"Some" drugs is right. Here in the eastern US, our streets are lined with mulberry trees (the unripe berries of which are hallucinogenic). And our government does nothing about it!
It's all about the time scale. Cox, for instance, on my $50/mo plan, offers peak bandwidth of 20Mbit/sec (so that picking up an MP3 from Amazon is nearly instantaneous), sustained average bandwidth of 5Mbit/sec (time scale unspecified, but my observations suggest it is 1 minute), and monthly average bandwidth of 40GB/month. They threaten to terminate you if you go over the monthly cap - which is dumb. They should do something like TW and either charge you or lower your peak.
So perhaps the term you are looking for is "average bandwidth" for some time period the average is taken over.
While the pricing seems a little high, I am *glad* that Time Warner is coming clean about the limitations of their service. A little competition will fix the pricing real quick.
Rather than automatically charge you more, some ISPs simply lower your peak bandwidth to ISDN levels - so that you still have (slow) internet access, and then offer to upgrade your monthly average for more dough. The peak bandwidth is restored as soon as the monthly average goes below the cap again.
I also think the "unlimited" advertising is a truth in advertising issue - and any company that advertises "unlimited" and then starts throttling you when you use "too much" should be prosecuted by the government for false advertising.
The only ancient culture I've read about that thought the earth was flat is early Babylon. Any people that either had ships on a large body of water, or were in contact with people that had ships on a large body of water, knew that the earth was round. You can't see a ship disappearing over the horizon and miss the implication.
As to Socrates, the Greeks even calculated the size of the earth pretty accurately.
The legend of people believing in a flat earth came from a work of pseudo-historical fiction by Washington Irving about Christopher Columbus, in which the author takes a lot of creative license.
Us modern types manage to have a Flat Earth Society despite this.
I not only run this at home, but at lots of small business customers. Has 3Ghz Pentium D (dual core, 64-bit). Get 2 large SATA drives (500G or more) and 2G or more ECC memory. Starting price is $400, but by the time you get the memory and disk upgraded, it is about $600, $800 with onsite maintenance. A big benefit for me for home use was it is *quiet*. It has a single large (and therefore quiet) fan with ducting to draw air over the CPU heatsink. Look for it in the "small business section" of Dell.
Drawbacks: only 2 drive bays (upgrade to 840 for 4 bays - not as quiet). No sensors - at least that lm_sensors knows about. I just monitor the disk temperature.
Configuration: run the 2 drives with software RAID1, and LVM on top of that. Create a small (100M) RAID1 boot partition at the beginning of the disk. The RedHat/Fedora installer can create this configuration. (I also save and mirror the Dell diagnostics partition, and add it to the grub boot menu.)
How about the part where he isn't accused of any actual crime, just "possession of a weapon". Sure, NY probably has some left wing "gun control" law, but "possession of a weapon" is a constitutionally protected right, not a crime in my book.
Like with everything else, there is an optimum level of employment that supports open pro bono open source activity. Note that producing open source can itself be a paid job - especially as a freelancer with the right clients. If Stallman had his way, *all* paid programming work would be on GPL software. Two years ago, it looked like my company might go under, and I was doing a lot more pro bono on the side. Now there is tons of work, and it is hard to squeeze in even a simple Fedora packaging project. On the other hand, I wouldn't be contributing much as a homeless person either.
As a citizen, I don't really care whether my gov (US) uses Microsoft, Mac, Solaris, Linux, or AmigaOS. I *do* care when they publish documents I need to work with in an undocumented proprietary format. And no, OOXML doesn't fix that (it only pretends to). Yes, I can get by with Open Office DOC importer for the time being.
Just sprinkle catnip on the input device.
I didn't find it on Google, but about 30 years ago I read an account of a creature like a giant sand dollar that was dislodged from the deep ocean by an undersea earthquake. I can't verify it until I find a reference, but I recall that the scientist examining it found that it was largely silicon, hydrogen, and sulphur (and decayed rapidly giving off H2S). His theory was that it was silicon based life - and that its chemistry required deep ocean temperature and pressure to remain stable. (Note that there are carbon based ocean creatures able to process silicon to create SiO2 structures.)
Your example illustrates localtime() behavior, *not* time() behavior. If you use a timezone that includes leapseconds, then:
$ export TZ=right/US/Eastern; date -d@1230768022; date -d@1230768023; date -d@1230768024
Wed Dec 31 18:59:59 EST 2008
Wed Dec 31 18:59:60 EST 2008
Wed Dec 31 19:00:00 EST 2008
Ya'll keep talking about localtime/mktime, when *I'm* talking 'bout time().
Yes, but we are not talking about mktime (kernel or libc) or localtime. We are talking about time(). If the intent of Posix is that particular time() values convert to particular localtimes() when using posix timezones, then linux is compliant. If you want the correct time of day, you use the "right" timezones - assuming you want the "correct" time of day to include leapseconds. Some systems apparently keep the correct time of day by slowing the time() clock for leapseconds. Doing this means time() is *not* the number of seconds since the epoch, but a smaller number.
To be posix compatible, you have to remove the leap seconds, creating aliased timestamps where the same value of time() refers to different seconds. By not having all that crap in there, and just counting seconds since the epoch, it is sane, simple, and non posix compatible.
However, it is easy to convert the sane result of time() to a posix result with a leap second table. And if I were delivering a posix compatible system, I would do that conditionally so that posix apps (assuming there are any that actually rely on time()%60 == seconds_in_minute) would work.
It is impossible to go the other direction, since the posix time is ambiguous.
Another interpretation could be that posix actually expects time() to be a simple count of seconds, but that the output of *localtime* should guarantee that time()%60 == seconds_in_minute. This would be a constraint on what timezones are allowed in a posix system. In fact, the more I think about it, I think this is what POSIX people really mean. You must use timezone files that do not handle leapseconds. So by not including leap seconds in the default timezones, linux is posix compatible. Only by using the timezone in the "right" directory do you get leapseconds, and are no longer compatible with posix - but time() still returns the same value. It is just the interpretation by localtime() that changes.
This is what I said at first, and what the linux man page implies.
Civil time is "baroque" but usable - every instant has a name, however complex the naming convention. Posix time is "broke" - it can't name every instant. Sane unix systems use a simple second count, which is both simple and usable, and can be converted to posix time when needed (hopefully never).
Civil time represents positive leap seconds as second 60:
23:59:59
23:59:60
00:00:00
00:00:01
DST is disambiguated by the Timezone name:
November 2, 2008 1:00:01 AM EST is an hour later than November 2, 2008 1:00:01 AM EDT.
You are right about the posix definition. But the posix definition is stupid and useless, because it can't unambiguously represent a timestamp - so it is ignored or reinterpreted by sane unix implementations. You can convert a sane clock (like the traditional second count) to posix time (or even most insane localtime based clocks), but not vice versa. So if anyone actually has to run a posix compatible application that is actually braindead enough to rely on time()%60 == seconds_in_minute, then they can set an environment to convert the output of time().
The linux man page for time() mentions the posix definition, and then says they made a mistake - and they really meant seconds since the epoch.
It doesn't matter how NTP protocol represents time - as long as it can be unambiguously converted to system time (i.e. just about anything except posix time could be used). The leap second flag *is* a little weird, but is just a wrinkle when converting to system time.
I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).
NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as
the number of seconds between a specified time and the Epoch, according
to a formula for conversion from UTC equivalent to conversion on the
naive basis that leap seconds are ignored and all years divisible by 4
are leap years. This value is not the same as the actual number of
seconds between the time and the Epoch, because of leap seconds and
because clocks are not required to be synchronised to a standard refer-
ence. The intention is that the interpretation of seconds since the
Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further
rationale.
Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?
A posix timestamp isn't even an unambiguous time reference. I can deal with discontinuities (just convert to linear time), but the end result of POSIX is utterly and totally useless (can't be unambiguously converted to linear time). For crying out loud, keeping system time as a well defined MDYHMS would be more usable than posix time - at least you can convert to something more manageable.
IMO, everyone should just ignore POSIX time. A Unix timestamp is a plain second count - regardless of the humped monstrosity decreed by POSIX. This can be easily converted to posix time , UTC, GMT, localtime, or any other desired scheme. Posix time can't. It is a non-starter.
Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation.
The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:
$ TZ="right/US/Eastern" date; TZ="US/Eastern" date
Sun Feb 8 17:52:42 EST 2009
Sun Feb 8 17:53:06 EST 2009
The take home salary is *not* the significant cost of hiring an American worker. You have FICA, Medicare, Unemployment insurance, Workers comp, plus lots more nickle and dime costs. Let me illustrate the end result with an example from a country even worse (in this respect - of course it is a nice place in other ways): Brazil.
Brazil got a socialist government that tried to end worker exploitation by decreeing a litany of benefits for all workers. Mandatory unemployment insurance, health care, maximum weekly hours, minimum wage, you name it. If you land a legal job in Brazil, you are really well taken care of - and you even get some spending money. The problem? Very few companies can afford to hire workers following all the rules. So instead, they offer jobs "under the table". You work for us, while officially unemployed, and we'll slip you money under the table. No benefits. No guarantees. This is what most workers in Brazil end up with. The end result is the opposite of the good intentions.
A friend was a lawyer in Brazil working for a non-profit that sued companies that failed to follow all the employment rules. The catch? His law firm hired *their* workers "under the table" with no benefits - they could not afford official workers as a non-profit.
A colleague of mine provided a "translation" of HP BASIC for april fools one year (35 years ago - HP2000). PRINT became SCRIBBLE, IF became SHOULD, GOTO became LEAP, LET became MAKE
10 I = 0
20 SHOULD I = 10 LEAP 50
30 SCRIBBLE I
35 MAKE I = I + 1
40 LEAP 20
Interestingly, no one had any trouble with their assignments (programs were stored tokenized, so you saw the new keywords in the "editor").