humans are social creatures, and are definitely influenced by the entire community that they are exposed to. it is the entire "village" that raises them, and not jsut the parents.
unfortunately, there is little community cohesion these days, especially in bedroom communities, and suburbs, and gates communities. dad doesnt go out to the polish club for a drink on fridays, mom doesnt belong to the newcomer's club, there are no businesses within walking distances, so no one knows the family. the police are a mysterious presence instead of friendly people with names.
it absolutely does take a village, unfortunately, popular american culture has eliminated the village square, and opted for cookie-cutter houses where they are protected from the big bad world, instead of interacting with each other, we learn to fear one another.
of course it takes a village to properly raise a child. do you somehow think that the child's entire world experience is controlled by their parents?
that being said - of course the parents should know what games their children are playing. i was absolutely stunned when i was waiting in line to buy my copy of GTA-SA, when a 12-ish year old was getting his mother to buy it for him.
i'm sure that if your 20% project became a big money maker, that google would take care of you, in a substantial way.
google is setting an example as an ethical tech company, and its about time.
Re:What exactly is a 'thin client' model then?
on
The PC Is Not Dead
·
· Score: 1
first: i am a software engineer with a thin client vendor.
sounds like you're netbooting into a system-recovery tool, not into a running system. netbooting you're way makes more sense than netbooting into a running system.
we've tried implementations of netbooting/peer-booting, and have always run away, screaming from the experience. i have a large installed base of netbooted thin clients, that still needs care and feeding.
how do we configure these units to point to the correct boot server? either we ask end-users to grunt through their network card setup, use a BootPROM on the device, or have a small ramdisk on flash, to let the end user configure the device.
the first is unwiedly for most users, and many admins, boot PROM's can be unforgivably picky regarding which OSs they'll let themselves load, and the third way still requires some local flash space.
how do we boot? we need to pull down a massive kernel, with all drivers, particulaly network drivers, built into the kernel. what if we're trying to do this on a Wireless network? what if we're trying to do this on a Token rung network? what if you're stuck with a god damn 10base2 network on a naval destroyer?
what about the rest of the root filesystem? NFS mounted? do we instead pull down tar's or cram package, and spew them into a large ramdisk?
how do we provide persistent application data? exported home directories? local flash?
how do we minimize network traffic? pulling down a huge ramdisk kills your load time, but once its down, you can run pretty much locally. NFS (more or less) relies on constant no-collision network connectivity, but provides a much faster bootup time.
how do you deal with device files? certain NFS server dont support these. certain nfs servers dont support SETUID bits.
some nfs servers dont support case sensitive filenames.
is the server that you're booting off of supposed to be usefull for anything else?
what happens when the entire site goes kablooie, and all peer boot clients simultaneously boot? can your sysinit handle collisions and dropped packets?
i do understand the first-look benefits of netbooting, but from experience, a generalized netbooting solution is a huge headache, and not worth the time, as flash is so god damn cheap.
the reason was: you didnt have to have big iron to run anything, and a small office of 10-20 people could justify the cost of a PC or two.
plus, you didnt need that huge overhead of staff.
Re:What exactly is a 'thin client' model then?
on
The PC Is Not Dead
·
· Score: 1
you have a central administration tool to update the small flash-storage-device (not necessarily compact flash, btw... whatever gave you that idea?)
the flash disk would be sufficiently small enough, around 32-128 MB's, depending on built-in-functionality reqs, that the bandwidth required to update them would be sufficiently small enough, and less than netbooting every time you boot.
netbooting is a horrible, horrible idea, and i have deployed a silly amount of netboot seats.
if you're on a local switched network, i would take X over ICA, any day of the week. why? because the X environment was designed to work transparently, and ICA is an ugly-ass hack.
if you are on any type of bandwidth limited, or unswitched network, ICA is clearly better.
Re:What exactly is a 'thin client' model then?
on
The PC Is Not Dead
·
· Score: 1
first, network booting is a horrible idea that should die a violent death. its unstable and generally a pain in teh ass to administer and support.
local flash is so damn cheap these days, that it really makes 0 sense to cobble together some god-awful TFTP solution.
the system on a USB idea is a neat idea, but with some limitations. You would not want your "core" OS on the Key, but would want data, and personal applications.
Slashdot Mirror
Ed Rendell, and, the mob would rejoice.
i hope that it isnt a senator - it is ridiculously easy to cast senate voting records as meaning just about anything.
Theres also the guv of Colorado.
last good, sane, liberal - Paul Wellstone - was off'd.
i mean, we have Kucinich, but he's a nutcase.
humans are social creatures, and are definitely influenced by the entire community that they are exposed to. it is the entire "village" that raises them, and not jsut the parents.
unfortunately, there is little community cohesion these days, especially in bedroom communities, and suburbs, and gates communities. dad doesnt go out to the polish club for a drink on fridays, mom doesnt belong to the newcomer's club, there are no businesses within walking distances, so no one knows the family. the police are a mysterious presence instead of friendly people with names.
it absolutely does take a village, unfortunately, popular american culture has eliminated the village square, and opted for cookie-cutter houses where they are protected from the big bad world, instead of interacting with each other, we learn to fear one another.
what hypocrisy?
i'm a 30 year old man. he's a 12 year old child.
some things are for grwon-ups, others arent.
if i wanted to go to a nudie bar, can i consider it bad form to see a father taking his 12 year old? is that hypocrisy?
of course it takes a village to properly raise a child. do you somehow think that the child's entire world experience is controlled by their parents?
that being said - of course the parents should know what games their children are playing. i was absolutely stunned when i was waiting in line to buy my copy of GTA-SA, when a 12-ish year old was getting his mother to buy it for him.
i'm sure that if your 20% project became a big money maker, that google would take care of you, in a substantial way.
google is setting an example as an ethical tech company, and its about time.
first: i am a software engineer with a thin client vendor.
sounds like you're netbooting into a system-recovery tool, not into a running system. netbooting you're way makes more sense than netbooting into a running system.
we've tried implementations
of netbooting/peer-booting, and have always run away, screaming from the experience. i have a large installed base of netbooted thin clients, that still needs care and feeding.
how do we configure these units to point to the correct boot server? either we ask end-users to grunt through their network card setup, use a BootPROM on the device, or have a small ramdisk on flash, to let the end user configure the device.
the first is unwiedly for most users, and many admins, boot PROM's can be unforgivably picky regarding which OSs they'll let themselves load, and the third way still requires some local flash space.
how do we boot? we need to pull down a massive kernel, with all drivers, particulaly network drivers, built into the kernel. what if we're trying to do this on a Wireless network? what if we're trying to do this on a Token rung network? what if you're stuck with a god damn 10base2 network on a naval destroyer?
what about the rest of the root filesystem? NFS mounted? do we instead pull down tar's or cram package, and spew them into a large ramdisk?
how do we provide persistent application data? exported home directories? local flash?
how do we minimize network traffic? pulling down a huge ramdisk kills your load time, but once its down, you can run pretty much locally. NFS (more or less) relies on constant no-collision network connectivity, but provides a much faster bootup time.
how do you deal with device files? certain NFS server dont support these. certain nfs servers dont support SETUID bits.
some nfs servers dont support case sensitive filenames.
is the server that you're booting off of supposed to be usefull for anything else?
what happens when the entire site goes kablooie, and all peer boot clients simultaneously boot? can your sysinit handle collisions and dropped packets?
i do understand the first-look benefits of netbooting, but from experience, a generalized netbooting solution is a huge headache, and not worth the time, as flash is so god damn cheap.
maybe you've missed my ranting on this thread, but net booting sucks.
you could probably have checkers on them, but the computational resources of chess would be wayyyy too much.
but visicalc ran on servers, too!
the reason was: you didnt have to have big iron to run anything, and a small office of 10-20 people could justify the cost of a PC or two.
plus, you didnt need that huge overhead of staff.
you have a central administration tool to update the small flash-storage-device (not necessarily compact flash, btw... whatever gave you that idea?)
the flash disk would be sufficiently small enough, around 32-128 MB's, depending on built-in-functionality reqs, that the bandwidth required to update them would be sufficiently small enough, and less than netbooting every time you boot.
netbooting is a horrible, horrible idea, and i have deployed a silly amount of netboot seats.
I've done netboot installs with over 7000 seats, in 500+ geographic locations, and they suck hairy mooseballs.
you're right with the "locally cached" thing. ROX is a good model. i should have been more
The point of the removable storage with local apps is to mitigate the "but i cant work if the server is down" problem.
not network boot.
network booting sucks big hairy mooseballs. trust me on this, it absolutely, positively sucks the big one.
local boot into minimal OS, local apps on removable media, local data on removable media, remote apps on servers, and remote data on servers.
that, is the future.
if you're on a local switched network, i would take X over ICA, any day of the week. why? because the X environment was designed to work transparently, and ICA is an ugly-ass hack.
if you are on any type of bandwidth limited, or unswitched network, ICA is clearly better.
first, network booting is a horrible idea that should die a violent death. its unstable and generally a pain in teh ass to administer and support.
local flash is so damn cheap these days, that it really makes 0 sense to cobble together some god-awful TFTP solution.
the system on a USB idea is a neat idea, but with some limitations. You would not want your "core" OS on the Key, but would want data, and personal applications.
most likely, your users are already relying on netowrk resources for productivity, anyway.
and why in the world would you lose a server? these things should never fall over. ever.
and then they lose the cheap-pc's due to moving parts, and dont gain the benefits of thin client manageability.
lets see...
my engineering dept has 15 people on a 2.4GHz 1GB RAM ICA/RDP server, and we all have thin clients.
we use this server for mail/office, and its more than enough.
re: browser
thats why people who do heavy browsing usually have a local browser.
when you were a contractor, did you control your own hours?
did you control where you did the work?
did you control the equipment you used?
if not, the company was in violation of law.
the part that makes it NOT LEGAL.
but these arent temp workers. they're temp-in-name only. they are expected to work specific hours, report to people, etc.
this is outsourcing.
they're abusing perma-temps by not giving them full benefits and protections.
morphine (and heroin, and hell all opiates and opiods) bind to the dopamine receptors.
yeh, so the sweet spot is generally the municipal bonds... what are orange county bonds at these days, anyway?