I mean, I could set up the Mach-O interpreter on Fedora and run fat binaries too... but why would I want to? I mean all the repositories are already architecture-labeled and its all pretty automatic so why do I care?
And if you're going to distribute binaries, just use 32-bit. If you want to be "transparent", ship a/lib64 directory and a shell script that launches your_binary_32 or your_binary_64 or your_binary_ia64 ala Matlab, Mathematica, Oracle... a lot of people who know how to package software. It's not rocket science.
Unless your flash memory could sustain writes of 20MB/s or more (unlikely).
Linux is very particular about what to swap out. Since it likes to mmap things, it'd much rather kill text/data and file cache first (none of which uses swap). That your combined bss/heap/stack or anonymously mmap pages would use up all your RAM doesn't happen all that often. And then its going to write out the entire process image all at once. It'll demand-page it back in. Write-outs would be so slow to flash that it'd outweigh the HD seekiness of page-in on resume.
Your linux system really shouldn't be swapping. Ever. That's a last resort data-preservation technique when you run too many things at once or a cron job goes nuts. You shouldn't worry unnecessarily about it and the performance aspects of swap media X or swap media Y.
But KHTML widgets still only hook into a single javascript thread, no matter how many of them there are. The javascript has run to completetion semantics. (This is kinda assumed by, well, everything out there, Web 1.0, Web 2.0, etc.)
This is better for user interaction than XUL if only because non-javascript pages can't be locked up by javascript non-responsiveness in another tab or frame. But if your google maps mashup gets into a infinite event loop then its going to screw up your google mail in your other tab. (I proposed a cross-browser approach to a solution to THAT particular problem).
... is that scoping rules be leveraged to work around this issue.
Most code that I'm aware of that works with multiple document roots tends to interact with other windows by function calls (and sometimes grabbing references to "foreign" objects which it later accesses). I think the way to avoid race conditions in these cases is to have the js engine marshall access to these cross-window objects transparently through the reference (so that all property access is actuall get/set calls). And then to protect those functions with mutexes, and block the "owning" thread from execution while the foreign process is modifying its globals.
Using a separate thread deliver cross-calls (and UI events) would be best so that you can avoid deadlocks.
Why would a pornographer want to advertise to members of a marketplace who are unlikely to have access to credit cards and the ability to pay said bills discreetly? It doesn't need to be illegal. There's no reason for them to spend money to do it in the first place.
I mean, I've never had problems with pornographic ads on non-adult sites back when I was a wee teenager even during the wild-west days of the internet.
The under-rated Lenevo T60 series is just what you're looking for. You can get a smaller 14", larger 15", or the 15" widescreen (which is a bit wider but the same "height" as the 14). The only drawback is it only has FW400 onboard. But it can be acquired with an extended-life battery and 160GB drive for under $1500. The T and X series are wonderful. Sturdy construction, excellent LCD panels (with heavy-duty hinges), they don't skimp out on the built in speakers either.
Firefox runs its own UI/user-experience engine. The whole XUL bit. Keypresses enter the front and they get treated the same on every platform. There are no isOS="MacOS" checks in the keyboard code in Chrome to determine what to do if you press up or down. It does the same thing everywhere.
So, use Camino. It uses the Mac UI and just renders using Gecko.
Spidermonkey has (simple) patches to support threading. While there's no built-in language primitives for it the core was almost already threadsafe anyway... it just needed an interface. I've actually played with it in jsext and I was kind of surprised.
Of course it's not so cleanly implemented as in java with monitors and critical sections being a language component. You have to interface objects that wrap stuff if you want to share mutable data between threads.
Nevertheless it would be a quicker fix for Firefox if they just had the core spawn off threads that handled the event loop for each document root (open window, tab, frame). And shunt off cross-document calls into a message queue in another thread for dispatch (same thread could be used to take messages from the interface and route them into the windows)
Meanwhile the event-trigger javascript running in each document would look at act single-threaded sequential and not know anything was different.
Yes. All XUL browsers have a single-threaded javascript instance running the interface. No. Safari's javascript engine is not multithreaded among open windows/tabs (but the interface is).
It would benefit all browsers if multi-threaded javascript were possible, and the event model kept "document" (i.e. window/tab) centric with cooperative event dispatch being the rule there unless otherwise specified in the language (for backwards compatibility).
Every MS program I've seen errors when you try to use backslashes as switch prefixes. Some accept hyphens instead of forward slashes, but all of them think you mean UNC paths when you use a backslash.
Technicians can test cards all the want before bringing them to the customer site. The bonding actually occurs at the head end, not in the card. They have to call up and give the head end reps the device ID and card ID so that the system can start transmitting the correct key stream with which the card will be able to decrypt and use to get at the symmetric content keys.
The cards themselves can be tested in a sandbox environment where the technician can control the encryption process, registration in the sandbox, and then verify the decryption.
ONI is the same way. But a lot of the operations parts of the Navy is a MS infrastructure. OTH you'll see Unix-likes and other estoeric stuff in some command/control situations and deployed systems but that's not the same thing.
While I'm all for compatibility, since the linux kernel doesn't even _pretend_ to work on other compilers, it's not exactly the sort of data point I would want to have ICC compared against and say: "look, it works". It's liable to over-fit the problem. Moreover the kernel is a self-contained entity with little dependancy on external libraries or APIs and any of the compatibility issues that arise in such cases would not be effectively tested.
I would rather see them applauding a XX%-success-rate on a test against a corpus of open source applications (with a mixture C/C++ and heavy library usage) and/or the GCC regression test suite.
Also, just because you can compile the linux kernel with ICC doesn't mean you should. There's no point. It's not like it's going to get any faster what with the handcoded assembly in the tricky parts and the bog standard techniques used elsewhere. And what's to say that some new driver that comes along breaks ICC compatibility for whatever reason since they only do testing with a limited range of GCC releases. It's not like Intel is doing regression checks for third party modules or anything.
Time to bust out WASTE I guess... there's no way in hell you can seperate illegal from legal behavior with that protocol. Unless you also want to block VPN access.
I was waiting and waiting and waiting for a return to the hat-switching job system from FF V and Tactics. Never happened. And while I thought the esper, materia, and junction systems of VI-VIII were interesting, you were still locked into character-specific abilities. Which was cool in ways for the story-detailed games with parties that you could mix/match. But I still missed it...
Then X-2 came out. Dress spheres. Meh, at least they remembered to make them _look good_ in the different outfits; that alone could make up for an unbalanced job. That was half of the fun.
FF V realized that over 10 years ago. Once you got all the jobs, it was three girls and a guy. And the girls had particular detailed outfits for tiny 16x16 sprites.
...then I realized that most of the gambits I thought I needed you didn't really need anyway.
Ally: KO? Useless. Ally: status? Mostly useless
Doing an Ally: name or Ally: Any with buffing/healing actions does it on demand anyway.
Those precise actions become useful later when you want to do things like auto-berserk a single character and then buff them or lure+reverse them later for particular nasty optional boss fights.
I don't know about that. Since FF IV power leveling has been just one of many strategies, the least elegant of them anyway. In these games (with exception of XI) you'd notice:
* Many enemies or bosses had clever ways to defeat quickly which were fun to discover and talk about with other players. * You can beat the 'interesting' enemies or bosses even at the lowest levels. * Some foes which you really couldn't beat unless you leveled significantly and discovered key items or skills. These foes were generally not "counted" for anything and were just fun to take on.
From IV and on you can find tons of guides and tips on how to complete low level, timed, or bestiary-complete games. It's less about the strategy required to beat the game (usually very simple), more about strategy to complete sidequests or achieve some goal not having anything to do with the story. And the games are even designed to accomodate such players.
I mean, why do you think they have the "Firefly" accessory in FFXII? Or why Quickenings ignore enemy stats and your current level?
Dude, you must be remembering some other 16-bit 2d RPGs. The pre-rendered dungeons in FF III and onward (up to VI) are just as aribtrary and devoid of stuff; big, empty tiled floors, a treasure chest at the end of a hidden hallway or whatever, walls that are all the same, save a few spot sprites.
Main reason battle areas were so sparse is to allow maximum manuverability when fighting enemies, and to keep the polycount down. 6 enemies, 3 party members, and two spell effects were at the limit of the PS2.
Outside areas had smaller draw distances and areas so they had more detail. Contrast to non-fighting areas. Towns, the inside of shops, etc. These were heavily detailed and full of stuff.
From the article:...to be religious is "to find the world significant."
Some of us find the world significant by the sheer audacity that it does exist. Why is this not enough? Why does there need to be a reason? This is what I find puzzling.
UAC is all about getting the user's input on activities that the Administrator would normally do (but not necessarily want to do if it was done behind their back).
AVC is a way for an end-administrator to customize policy (or get hints on what files or network features to label for access by a service). Generally, the system administrator SHOULD NOT have to create policy unless the administrator is deploying a novel service. And its' not interactive; you don't use it during normal use, you use it during testing to refine your policy.
A similar approach with vastly different intents and use cases.
Slashdot Mirror
I mean, I could set up the Mach-O interpreter on Fedora and run fat binaries too... but why would I want to? I mean all the repositories are already architecture-labeled and its all pretty automatic so why do I care?
/lib64 directory and a shell script that launches your_binary_32 or your_binary_64 or your_binary_ia64 ala Matlab, Mathematica, Oracle ... a lot of people who know how to package software. It's not rocket science.
And if you're going to distribute binaries, just use 32-bit. If you want to be "transparent", ship a
NT
Unless your flash memory could sustain writes of 20MB/s or more (unlikely).
Linux is very particular about what to swap out. Since it likes to mmap things, it'd much rather kill text/data and file cache first (none of which uses swap). That your combined bss/heap/stack or anonymously mmap pages would use up all your RAM doesn't happen all that often. And then its going to write out the entire process image all at once. It'll demand-page it back in.
Write-outs would be so slow to flash that it'd outweigh the HD seekiness of page-in on resume.
Your linux system really shouldn't be swapping. Ever. That's a last resort data-preservation technique when you run too many things at once or a cron job goes nuts. You shouldn't worry unnecessarily about it and the performance aspects of swap media X or swap media Y.
Safari isn't XUL, sure (I didn't claim it was).
But KHTML widgets still only hook into a single javascript thread, no matter how many of them there are. The javascript has run to completetion semantics. (This is kinda assumed by, well, everything out there, Web 1.0, Web 2.0, etc.)
This is better for user interaction than XUL if only because non-javascript pages can't be locked up by javascript non-responsiveness in another tab or frame. But if your google maps mashup gets into a infinite event loop then its going to screw up your google mail in your other tab. (I proposed a cross-browser approach to a solution to THAT particular problem).
... is that scoping rules be leveraged to work around this issue.
Most code that I'm aware of that works with multiple document roots tends to interact with other windows by function calls (and sometimes grabbing references to "foreign" objects which it later accesses). I think the way to avoid race conditions in these cases is to have the js engine marshall access to these cross-window objects transparently through the reference (so that all property access is actuall get/set calls). And then to protect those functions with mutexes, and block the "owning" thread from execution while the foreign process is modifying its globals.
Using a separate thread deliver cross-calls (and UI events) would be best so that you can avoid deadlocks.
...you think you'll be thrown clear of an accident.
If that is the case, you really do need mommy to tell you what to do, because you're apparently too stupid to evaluate risks yourself.
Why would a pornographer want to advertise to members of a marketplace who are unlikely to have access to credit cards and the ability to pay said bills discreetly?
It doesn't need to be illegal. There's no reason for them to spend money to do it in the first place.
I mean, I've never had problems with pornographic ads on non-adult sites back when I was a wee teenager even during the wild-west days of the internet.
It's just puritanical bullshit, same as always.
If you could put blocks on your gametes to make sure only the chromosomes you wanted to combine would combine; would you?
Blond hair, no heart-disease from my pop, and let's aim for hazel eyes.
It wouldn't be abortion. It'd be selective contraception.
I mean, you're allowed to pick your mate and fantasize about what your children will look like right now. So why not have a more hands on approach?
The under-rated Lenevo T60 series is just what you're looking for. You can get a smaller 14", larger 15", or the 15" widescreen (which is a bit wider but the same "height" as the 14).
The only drawback is it only has FW400 onboard. But it can be acquired with an extended-life battery and 160GB drive for under $1500. The T and X series are wonderful. Sturdy construction, excellent LCD panels (with heavy-duty hinges), they don't skimp out on the built in speakers either.
Dell laptops are kinda... bleh.
Firefox runs its own UI/user-experience engine. The whole XUL bit. Keypresses enter the front and they get treated the same on every platform. There are no isOS="MacOS" checks in the keyboard code in Chrome to determine what to do if you press up or down. It does the same thing everywhere.
So, use Camino. It uses the Mac UI and just renders using Gecko.
Spidermonkey has (simple) patches to support threading. While there's no built-in language primitives for it the core was almost already threadsafe anyway... it just needed an interface.
I've actually played with it in jsext and I was kind of surprised.
Of course it's not so cleanly implemented as in java with monitors and critical sections being a language component. You have to interface objects that wrap stuff if you want to share mutable data between threads.
Nevertheless it would be a quicker fix for Firefox if they just had the core spawn off threads that handled the event loop for each document root (open window, tab, frame). And shunt off cross-document calls into a message queue in another thread for dispatch (same thread could be used to take messages from the interface and route them into the windows)
Meanwhile the event-trigger javascript running in each document would look at act single-threaded sequential and not know anything was different.
Yes. All XUL browsers have a single-threaded javascript instance running the interface.
No. Safari's javascript engine is not multithreaded among open windows/tabs (but the interface is).
It would benefit all browsers if multi-threaded javascript were possible, and the event model kept "document" (i.e. window/tab) centric with cooperative event dispatch being the rule there unless otherwise specified in the language (for backwards compatibility).
Every MS program I've seen errors when you try to use backslashes as switch prefixes. Some accept hyphens instead of forward slashes, but all of them think you mean UNC paths when you use a backslash.
Technicians can test cards all the want before bringing them to the customer site.
The bonding actually occurs at the head end, not in the card.
They have to call up and give the head end reps the device ID and card ID so that the system can start transmitting the correct key stream with which the card will be able to decrypt and use to get at the symmetric content keys.
The cards themselves can be tested in a sandbox environment where the technician can control the encryption process, registration in the sandbox, and then verify the decryption.
The firmware disable recording when protected content is detected. (Check the fine print)
ONI is the same way.
But a lot of the operations parts of the Navy is a MS infrastructure.
OTH you'll see Unix-likes and other estoeric stuff in some command/control situations and deployed systems but that's not the same thing.
While I'm all for compatibility, since the linux kernel doesn't even _pretend_ to work on other compilers, it's not exactly the sort of data point I would want to have ICC compared against and say: "look, it works". It's liable to over-fit the problem. Moreover the kernel is a self-contained entity with little dependancy on external libraries or APIs and any of the compatibility issues that arise in such cases would not be effectively tested.
I would rather see them applauding a XX%-success-rate on a test against a corpus of open source applications (with a mixture C/C++ and heavy library usage) and/or the GCC regression test suite.
Also, just because you can compile the linux kernel with ICC doesn't mean you should. There's no point. It's not like it's going to get any faster what with the handcoded assembly in the tricky parts and the bog standard techniques used elsewhere.
And what's to say that some new driver that comes along breaks ICC compatibility for whatever reason since they only do testing with a limited range of GCC releases. It's not like Intel is doing regression checks for third party modules or anything.
Time to bust out WASTE I guess... there's no way in hell you can seperate illegal from legal behavior with that protocol. Unless you also want to block VPN access.
I was waiting and waiting and waiting for a return to the hat-switching job system from FF V and Tactics. Never happened. And while I thought the esper, materia, and junction systems of VI-VIII were interesting, you were still locked into character-specific abilities. Which was cool in ways for the story-detailed games with parties that you could mix/match. But I still missed it...
Then X-2 came out. Dress spheres. Meh, at least they remembered to make them _look good_ in the different outfits; that alone could make up for an unbalanced job. That was half of the fun.
FF V realized that over 10 years ago. Once you got all the jobs, it was three girls and a guy. And the girls had particular detailed outfits for tiny 16x16 sprites.
...then I realized that most of the gambits I thought I needed you didn't really need anyway.
Ally: KO? Useless.
Ally: status? Mostly useless
Doing an Ally: name or Ally: Any with buffing/healing actions does it on demand anyway.
Those precise actions become useful later when you want to do things like auto-berserk a single character and then buff them or lure+reverse them later for particular nasty optional boss fights.
I don't know about that. Since FF IV power leveling has been just one of many strategies, the least elegant of them anyway. In these games (with exception of XI) you'd notice:
* Many enemies or bosses had clever ways to defeat quickly which were fun to discover and talk about with other players.
* You can beat the 'interesting' enemies or bosses even at the lowest levels.
* Some foes which you really couldn't beat unless you leveled significantly and discovered key items or skills. These foes were generally not "counted" for anything and were just fun to take on.
From IV and on you can find tons of guides and tips on how to complete low level, timed, or bestiary-complete games. It's less about the strategy required to beat the game (usually very simple), more about strategy to complete sidequests or achieve some goal not having anything to do with the story. And the games are even designed to accomodate such players.
I mean, why do you think they have the "Firefly" accessory in FFXII? Or why Quickenings ignore enemy stats and your current level?
Dude, you must be remembering some other 16-bit 2d RPGs. The pre-rendered dungeons in FF III and onward (up to VI) are just as aribtrary and devoid of stuff; big, empty tiled floors, a treasure chest at the end of a hidden hallway or whatever, walls that are all the same, save a few spot sprites.
Main reason battle areas were so sparse is to allow maximum manuverability when fighting enemies, and to keep the polycount down. 6 enemies, 3 party members, and two spell effects were at the limit of the PS2.
Outside areas had smaller draw distances and areas so they had more detail.
Contrast to non-fighting areas. Towns, the inside of shops, etc. These were heavily detailed and full of stuff.
It's all about what the PS2 can crank out.
From the article: ...to be religious is "to find the world significant."
Some of us find the world significant by the sheer audacity that it does exist.
Why is this not enough?
Why does there need to be a reason? This is what I find puzzling.
Doom 3, plot, in the same sentence?
Go back to sleep, Anonymous!
UAC is all about getting the user's input on activities that the Administrator would normally do (but not necessarily want to do if it was done behind their back).
AVC is a way for an end-administrator to customize policy (or get hints on what files or network features to label for access by a service). Generally, the system administrator SHOULD NOT have to create policy unless the administrator is deploying a novel service. And its' not interactive; you don't use it during normal use, you use it during testing to refine your policy.
A similar approach with vastly different intents and use cases.