Their user guides for OmniGraffle (one of the best diagramming tools i've ever had the pleasure of using) and OmniWeb (again, a glorious Mac OS browser with popup dialog squelching, real cookie management, banner ad obliteration, and other great goodies) are extremely enjoyable to read--you can tell the writers had fun putting the documentation together.
While in US politics we see a tendency towards anti-intellectualism, with idiocies like congressmembers saying "I'm not a lawyer, but..." or "I'm not some highfalutin' professor, but...", many Latin American politicians do have a tendency to be much more educated, because credentials are still the easiest way to open doors. Don't forget, in a hierarchical society with heavy class distinctions, anything that makes others thing you're ahead of them will work. You'd be surprised at the kind of brilliance (and overintellectualized bull) you see in south american legislation... for example, the Colombian constitution, rewritten in '89, provides the protection of "Habeas data"--citizens own the data about themselves stored in computer systems. Sure, you see donkey's-ass-inspired laws all the time, but some of the greatest social science lit. from Latin America comes from politicians...
Villanueva is his last name, most likely his father's last name, Nuñez is most likely his mother's last, kept around because Villanueva is a last name usually associated with leftist politics in Peru.
I'd refer to him as "Honorable Dr. Villanueva Nuñ"
Peru's national languages are Spanish, Quechua and Aymara. Portuguese is on the other side of the amazon, rapaz.
As for getting residence, under Fujimori (probably changed recently), in order to get residence you needed to guarantee an investment of at least $10k in enterprise in order to qualify for residence.
I used to work in usage billing, so I can say that you're all right in your own overconfident slashdot ways.
In some places, the switch is configured to record all local calls with complete information (origination, termination, billable number, duration, type of call).
In some other places, the switch is configured to record only counts of local calls and their respective billable number.
Why? Because if a company owns its switch and it won't be rating a caller's local calls individually, then there's no reason to collect all the data and run it through the system. But, if there's a legal reason why it must be done (customer request, subpoena) or if there's a need to verify network use, or if the line belongs to a customer that is serviced by another phone company that's buying bulk service from the switch owner, then the company will turn on local call recording.
Since most telephone traffic in a city IS local, and if most of it won't be billed per call but rather as a monthly cost, then collecting and rating all that data represents costs that the are unnecessary.
Anyone know if they're building in multitasking?
on
Palm OS 5.0 Preview
·
· Score: 2, Insightful
Palm programming is sweet, simple, reminiscent of early MacOS programming.
But... only the foreground application can do anything. Like a mac pre-OS 7.0 sans-Switcher. Makes it very hard to build apps that listen patiently in the background for something to do something else...
Perhaps the Handspring folks resolved the can't-listen-on-transmitter-while-playing-DragonBa ne problem with the Treo, but it still won't solve the let-me-catalog-my-128meg-CF-card-in-the-background problem...
I write to express my dissatisfaction with the Proposed Final Judgment (PFJ) for USA vs. Microsoft. While time limitations prevent me from conducting an exhaustive review of all the aspects of the provisions of the Final Judgment that I find to fail the public interest, allow me to focus on two particular issues that are of crucial importance:
1) The exclusion of Microsoft's handheld version of Windows (i.e. Windows CE and variants, Windows for Automotive, Windows NT Embedded, and Windows XP Embedded from the definition of "Windows Operating System Product" delineated in Section VI, Item U of the PFJ;
2) Provisions of Section III, Item J which give Microsoft broad discretion on determining which parties are eligible to receive API, Documentation or Communications Protocol information.
1) Handheld and embedded operating systems
I have been working as a user of handheld devices for almost ten years and have been an applications developer for three of those ten. It has been very clear to me that portable devices will be a fundamental domain of computing technology, perhaps even replacing the desktop computer as a central unit of processing, in the near term. While there are various players in the handheld and mobile marketplace, Microsoft is a competitor that has historically used its weight to stifle innovation in this marketplace until it was ready to embrace it.
In terms of its APIs, the embedded versions of Microsoft's operating systems are modeled closely--sometimes even ported directly--on its Win32 API for desktop operating system development. These versions of the operating system, designed to be stored in quickly-accessible RAM or ROM rather than on disk, and with an apparently closer connection to the hardware in which they're operating, are not significantly technically different from the existing desktop Windows technology, save for their portability. Microsoft itself, when advocating for the Embedded version of its operating system, argues that this close tie provides one of the main reasons why developers should adopt its solution:
"Windows XP Embedded is the componentized version of the leading desktop operating system, enabling rapid development of the most reliable and full-featured connected devices. Based on the same binaries as Windows XP Professional, Windows XP Embedded enables embedded developers to individually select only the rich features they need for customized, reduced-footprint embedded devices." [
http://www.microsoft.com/windows/embedded/xp/eval uation/overview/default.asp -- accessed Jan 23, 2002]
The versions of the Microsoft OS for handheld and mobile devices, (Windows CE and derivatives including Windows CE for Handheld PC, Windows CE for Palm-size PC, Windows CE for Desktop PC) are tied equally closely in Microsoft's eyes:
" The Windows CE operating system is based on the Microsoft Win32® application programming interface. Therefore, you can enhance your applications by using exposed APIs from bundled applications."
[http://www.microsoft.com/mobile/developer/downl oa ds/ppcsdk2002.asp -- accessed January 23, 2002]
Microsoft's own behavior in the handheld and mobile marketplace reflects similar actions to those presented in the Court's Findings of Fact, including concerted action to protect applications barrier to entry by performing ongoing modifications to its handheld data storage methodologies, by modifying established connectivity protocols (including the infrared communications protocols between competitors' handheld devices), and by maintaining its own data transfer protocols closed, thus thwarting the efforts of middleware vendors and non-Windows handheld device manufacturers to provide connectivity solutions that make full use of the capabilities of users' desktop computer hardware to connect with mobile devices.
Because of the rising capabilities and reduction in size of microprocessors, along with the quickly falling cost of flashable (rewritable) ROM and high-capacity RAM, it is very likely indeed that what we call embedded or mobile systems today will come to replace wholly desktop-based solutions for everyday users in the near and mid-range future. Embedded systems will (and do) reside in automobiles, household appliances, communications devices, and just about every other type of device that uses electronics to perform complex functions.
Allowing Microsoft to extend its monopoly into the embedded and mobile marketplace while remaining unfettered by the consequences of its previous anti-competitive behavior in the desktop operating systems marketplace is detrimental to the public interest.
2) Viable Business requirement
This point is much more brief, but equally important. In giving Microsoft the power to determine that a company "meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business" before receiving API and Documentation, or Communication Protocol information, it effectively gives Microsoft the power to exclude open source and free software developers from building systems that are fully interoperable with existing solutions provided by Microsoft, mostly because these developers are not engaging in "viable business". Indeed, many of these companies are not engaged in business at all, but are working through the concepts of sharing and widely disseminating usable code and applications. Powerful and open public goods such as the Internet and Linux grew through this kind of non-business activity. This item effectively shuts out the public interest in interoperability and standards compliance by giving Microsoft the power to define what is authentic and viable. Microsoft CEO Steve Ballmer's rhetoric regarding Linux as a cancer demonstrates their predisposition to exclude open source systems from any and all consideration for interoperability and access:
"The only thing we have a problem with is when the government funds open-source work. Government funding should be for work that is available to everybody. Open source is not available to commercial companies. The way the license is written, if you use any open-source software, you have to make the rest of your software open source. If the government wants to put something in the public domain, it should. Linux is not in the public domain." [
http://www.linuxmax.net/maxnews.php?ArticleID=26 -- Accessed January 23,2002]
Aside from Mr. Ballmer's odd reasoning that an operating system for which the source is open and available to anyone is not in the public domain, his reasoning that open source licenses are not commercially viable makes a statement of predisposition that I have no doubt would be used as legally acceptable parameters, under the PFJ, to thwart public efforts at building an interoperable, free operating system.
I sincerely hope that Microsoft will have to atone for its extensive history of anticompetitive behavior. However, it is clear to me, and to those of us in the technology industry who have seen Microsoft as a company uninterested in cooperating, that this PFJ would do little to force that atonement and would do much to provide Microsoft a legal platform from which to continue its anticompetitive behavior.
"rationalization" = uma desculpa mà pra uma limitação pessoal = bad excuse for a personal limitation;
"rationing" = soferimento causado por administradores estupidos = suffering due to imbeciles making decisions
I interviewed with the Senate Democratic Technology and Communications Committee -- the group that does all the tech and tech support for Dems in the Senate. The amount of support they offered to senators was extensive. The setups for communications are fairly standard--POP3 and SMTP servers on both Mac and Windows, web hosting, scripts to automate web mangement tasks. Some fancy video production equipment as well. No setups I was aware of to do more than the mail filtering that's currently available to everyday users. They're tech savvy folks, at least at the DTCC.
That's not where the problem lies.
I used to work for a nonprofit that had as mission educating congressmembers on technology issues, back when the net was not on Oprah. This nonprofit had a series of demonstrations on constituent issue/contact/request tracking software--a system for staffers to look at correspondence received by the congressmember, enter key facts about it into a database, and then be able to generate reports on how many people wrote this month about a or b or c, who wanted a flag flown in memory of so-and-so, etc.
The software worked, and well. What didn't was the fact that the rate of adoption of this technology by the congressional offices was very disparate. Each congressmember's office has a different amount of money available to it for expenses, and this has to do with many factors including state population, the amount of financial support that the state gives its federal representative, the seniority of the congressmember, the amount of money the congressmember raised during the campaign that s/he decides to use for things such as serving constituents, what the party (tech, as most other things on the hill, are party based) allocates for it, etc.
Which means that the software to do this fancy mail management stuff specific to congress is there, but congressional turnover eliminates the possibility of continuity, the cost makes it harder for the smaller offices to use, and . The amount of money that the federal government gives congressmembers for staff, supplies, equipment and such is fairly tight. Organizations like the DTCC end up having to provide it out of general funds raised by their party. That's where some of the party fundraising goes to, folks. True, it also might pay for dinner cruises on the Potomac, but really folks, cynicism can only take you so far before you become fascetious.
So, what do we do as everyday citizens to improve our ability to influence our congresmembers, using technology?
The answer to everything--open source.
Create a toolkit for anyone in congress to use, free of charge, to track and respond to constituent issues, or issues of importance to the nation as large whether or not from constituents. Make it a free, point-and-click installation, that runs on whatever they use and that can, because of the way it's designed, give the congressmember not just a view of what's out there on the issue front but also what has been there. Make the code open and available to all so that it becomes both a public good and something we can all supervise
It's OUR government after all. Let's treat it as such. As long as we continue seeing it as this big old enemy out to get us, those out there who treat it as a buddy that wants presents will get more out of it than we will.
Their user guides for OmniGraffle (one of the best diagramming tools i've ever had the pleasure of using) and OmniWeb (again, a glorious Mac OS browser with popup dialog squelching, real cookie management, banner ad obliteration, and other great goodies) are extremely enjoyable to read--you can tell the writers had fun putting the documentation together.
Yub nub, eee chop yub nub...
While in US politics we see a tendency towards anti-intellectualism, with idiocies like congressmembers saying "I'm not a lawyer, but..." or "I'm not some highfalutin' professor, but...", many Latin American politicians do have a tendency to be much more educated, because credentials are still the easiest way to open doors. Don't forget, in a hierarchical society with heavy class distinctions, anything that makes others thing you're ahead of them will work.
You'd be surprised at the kind of brilliance (and overintellectualized bull) you see in south american legislation... for example, the Colombian constitution, rewritten in '89, provides the protection of "Habeas data"--citizens own the data about themselves stored in computer systems.
Sure, you see donkey's-ass-inspired laws all the time, but some of the greatest social science lit. from Latin America comes from politicians...
Villanueva is his last name, most likely his father's last name, Nuñez is most likely his mother's last, kept around because Villanueva is a last name usually associated with leftist politics in Peru.
I'd refer to him as "Honorable Dr. Villanueva Nuñ"
Peru's national languages are Spanish, Quechua and Aymara. Portuguese is on the other side of the amazon, rapaz.
As for getting residence, under Fujimori (probably changed recently), in order to get residence you needed to guarantee an investment of at least $10k in enterprise in order to qualify for residence.
I used to work in usage billing, so I can say that you're all right in your own overconfident slashdot ways.
In some places, the switch is configured to record all local calls with complete information (origination, termination, billable number, duration, type of call).
In some other places, the switch is configured to record only counts of local calls and their respective billable number.
Why? Because if a company owns its switch and it won't be rating a caller's local calls individually, then there's no reason to collect all the data and run it through the system. But, if there's a legal reason why it must be done (customer request, subpoena) or if there's a need to verify network use, or if the line belongs to a customer that is serviced by another phone company that's buying bulk service from the switch owner, then the company will turn on local call recording.
Since most telephone traffic in a city IS local, and if most of it won't be billed per call but rather as a monthly cost, then collecting and rating all that data represents costs that the are unnecessary.
Palm programming is sweet, simple, reminiscent of early MacOS programming.
a ne problem with the Treo, but it still won't solve the let-me-catalog-my-128meg-CF-card-in-the-background problem...
But... only the foreground application can do anything. Like a mac pre-OS 7.0 sans-Switcher. Makes it very hard to build apps that listen patiently in the background for something to do something else...
I wish this weren't a limitation--i'd be able to tell clients to steer clear from WinCE and go with a solid platform. But, despite that platform being horrible to program, flaky even after 4 major rewrites, and unwilling to play well with others, it still has that thing that PalmOS doesn't--background processes that listen to transmitters, network interfaces, and all that good stuff. So, those looking to build something that's more businessy than Vexed© have to go with shiny m$ approved devices that have a battery life of roughly 8 minutes.
Perhaps the Handspring folks resolved the can't-listen-on-transmitter-while-playing-DragonB
I write to express my dissatisfaction with the Proposed Final Judgment (PFJ) for USA vs. Microsoft. While time limitations prevent me from conducting an exhaustive review of all the aspects of the provisions of the Final Judgment that I find to fail the public interest, allow me to focus on two particular issues that are of crucial importance:
1) The exclusion of Microsoft's handheld version of Windows (i.e. Windows CE and variants, Windows for Automotive, Windows NT Embedded, and Windows XP Embedded from the definition of "Windows Operating System Product" delineated in Section VI, Item U of the PFJ;
2) Provisions of Section III, Item J which give Microsoft broad discretion on determining which parties are eligible to receive API, Documentation or Communications Protocol information.
1) Handheld and embedded operating systems
I have been working as a user of handheld devices for almost ten years and have been an applications developer for three of those ten. It has been very clear to me that portable devices will be a fundamental domain of computing technology, perhaps even replacing the desktop computer as a central unit of processing, in the near term. While there are various players in the handheld and mobile marketplace, Microsoft is a competitor that has historically used its weight to stifle innovation in this marketplace until it was ready to embrace it.
In terms of its APIs, the embedded versions of Microsoft's operating systems are modeled closely--sometimes even ported directly--on its Win32 API for desktop operating system development. These versions of the operating system, designed to be stored in quickly-accessible RAM or ROM rather than on disk, and with an apparently closer connection to the hardware in which they're operating, are not significantly technically different from the existing desktop Windows technology, save for their portability. Microsoft itself, when advocating for the Embedded version of its operating system, argues that this close tie provides one of the main reasons why developers should adopt its solution:
The versions of the Microsoft OS for handheld and mobile devices, (Windows CE and derivatives including Windows CE for Handheld PC, Windows CE for Palm-size PC, Windows CE for Desktop PC) are tied equally closely in Microsoft's eyes:
Microsoft's own behavior in the handheld and mobile marketplace reflects similar actions to those presented in the Court's Findings of Fact, including concerted action to protect applications barrier to entry by performing ongoing modifications to its handheld data storage methodologies, by modifying established connectivity protocols (including the infrared communications protocols between competitors' handheld devices), and by maintaining its own data transfer protocols closed, thus thwarting the efforts of middleware vendors and non-Windows handheld device manufacturers to provide connectivity solutions that make full use of the capabilities of users' desktop computer hardware to connect with mobile devices.
Because of the rising capabilities and reduction in size of microprocessors, along with the quickly falling cost of flashable (rewritable) ROM and high-capacity RAM, it is very likely indeed that what we call embedded or mobile systems today will come to replace wholly desktop-based solutions for everyday users in the near and mid-range future. Embedded systems will (and do) reside in automobiles, household appliances, communications devices, and just about every other type of device that uses electronics to perform complex functions.
Allowing Microsoft to extend its monopoly into the embedded and mobile marketplace while remaining unfettered by the consequences of its previous anti-competitive behavior in the desktop operating systems marketplace is detrimental to the public interest.
2) Viable Business requirement
This point is much more brief, but equally important. In giving Microsoft the power to determine that a company "meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business" before receiving API and Documentation, or Communication Protocol information, it effectively gives Microsoft the power to exclude open source and free software developers from building systems that are fully interoperable with existing solutions provided by Microsoft, mostly because these developers are not engaging in "viable business". Indeed, many of these companies are not engaged in business at all, but are working through the concepts of sharing and widely disseminating usable code and applications. Powerful and open public goods such as the Internet and Linux grew through this kind of non-business activity. This item effectively shuts out the public interest in interoperability and standards compliance by giving Microsoft the power to define what is authentic and viable. Microsoft CEO Steve Ballmer's rhetoric regarding Linux as a cancer demonstrates their predisposition to exclude open source systems from any and all consideration for interoperability and access:
Aside from Mr. Ballmer's odd reasoning that an operating system for which the source is open and available to anyone is not in the public domain, his reasoning that open source licenses are not commercially viable makes a statement of predisposition that I have no doubt would be used as legally acceptable parameters, under the PFJ, to thwart public efforts at building an interoperable, free operating system.
I sincerely hope that Microsoft will have to atone for its extensive history of anticompetitive behavior. However, it is clear to me, and to those of us in the technology industry who have seen Microsoft as a company uninterested in cooperating, that this PFJ would do little to force that atonement and would do much to provide Microsoft a legal platform from which to continue its anticompetitive behavior.
Sincerely,
"rationalization" = uma desculpa mà pra uma limitação pessoal = bad excuse for a personal limitation;
"rationing" = soferimento causado por administradores estupidos = suffering due to imbeciles making decisions
I interviewed with the Senate Democratic Technology and Communications Committee -- the group that does all the tech and tech support for Dems in the Senate. The amount of support they offered to senators was extensive. The setups for communications are fairly standard--POP3 and SMTP servers on both Mac and Windows, web hosting, scripts to automate web mangement tasks. Some fancy video production equipment as well. No setups I was aware of to do more than the mail filtering that's currently available to everyday users. They're tech savvy folks, at least at the DTCC.
That's not where the problem lies.
I used to work for a nonprofit that had as mission educating congressmembers on technology issues, back when the net was not on Oprah. This nonprofit had a series of demonstrations on constituent issue/contact/request tracking software--a system for staffers to look at correspondence received by the congressmember, enter key facts about it into a database, and then be able to generate reports on how many people wrote this month about a or b or c, who wanted a flag flown in memory of so-and-so, etc.
The software worked, and well. What didn't was the fact that the rate of adoption of this technology by the congressional offices was very disparate. Each congressmember's office has a different amount of money available to it for expenses, and this has to do with many factors including state population, the amount of financial support that the state gives its federal representative, the seniority of the congressmember, the amount of money the congressmember raised during the campaign that s/he decides to use for things such as serving constituents, what the party (tech, as most other things on the hill, are party based) allocates for it, etc.
Which means that the software to do this fancy mail management stuff specific to congress is there, but congressional turnover eliminates the possibility of continuity, the cost makes it harder for the smaller offices to use, and . The amount of money that the federal government gives congressmembers for staff, supplies, equipment and such is fairly tight. Organizations like the DTCC end up having to provide it out of general funds raised by their party. That's where some of the party fundraising goes to, folks. True, it also might pay for dinner cruises on the Potomac, but really folks, cynicism can only take you so far before you become fascetious.
So, what do we do as everyday citizens to improve our ability to influence our congresmembers, using technology?
The answer to everything--open source.
Create a toolkit for anyone in congress to use, free of charge, to track and respond to constituent issues, or issues of importance to the nation as large whether or not from constituents. Make it a free, point-and-click installation, that runs on whatever they use and that can, because of the way it's designed, give the congressmember not just a view of what's out there on the issue front but also what has been there. Make the code open and available to all so that it becomes both a public good and something we can all supervise
It's OUR government after all. Let's treat it as such. As long as we continue seeing it as this big old enemy out to get us, those out there who treat it as a buddy that wants presents will get more out of it than we will.