text:
True to form, a little slower than promised, but below are the basics on the applications for the next release of wattOS.
Browser - Chromium
Email client - Postler
Contacts - Dexter
Music - Audacious
Password Manager - keepassX
Picture editor - Fotoxx
Video/Media - VLC
Spreadsheet - Gnumeric
Word processing - Abiword
simple text editor - Leafpad
Bittorrent - Transmission
Microblogging (Twitter/Facebook,etc) - Gwibber
And some other new exciting additions that will speed up your desktop experience (think control panel type configuration options in one simple window rather than menu hunting for various settings.)
Expect screenshots and more details to follow shortly. wattOS R4 has been running in pre-production for several weeks on several systems while I shake out all the applications and various configurations, etc.
Should be very nice and staying true to the lightweight, simple core. :)
biff baxter said:
Thanks for the feedback folks....you can always install firefox, or midori, or other browser of choice. Thats why I love Linux :)
How do you know? :lol:
I still have a partition left.
Mint LMDE (so Debian), Mint Ubuntu, Mint Xfce, PCLOS Gnome with MBR for the multiboot, PCLOS KDE and wattOS.
PCLOS KDE is not necessary any more. I 'have seen it'. I keep it as (Clonezilla) clone like it is now.
I do keep more clones like Mageia (ex. Mandriva developers I believe). They are reinstalled in 2 minutes if necessary.
This all after the introduction of Gnome 3 (after all those years of problems with KDE 4.x.x developement after the destruction of KDE 3.5).
235 Gig. But that is not so big. And they are not expensive these days.
I have also data-backup-disks in this rather simple desktop. All together about 800 Gig. And those extra disks could also be partitioned and used for 'distro's'. That would be a little madness of course. But it is with a not to very special machine almost unlimited of course in a multiboot config.
Leenie Gilmore said:
Distro hopping is FUN!
I don't think so, I hate it, it consumes a lot of time. But one has to keep eyes open today.
In short: I have to do my work with the PC, so... Let spend some time at searching the good OS-es. And I found out.
(Mint) LMDE Gnome/KDE is perfect and very stable, Mint Ubuntu Xfce and Gnome too (but Gnome is a bottelneck, also for Xfce dependency), WattOS is great, because it is not very dependent on other desktops like KDE and Gnome and it does all, and there could be the problem of Gtk and Qt which may be not such an enormous problem for WattOS. There's like in Mint a lot of software available (Debian, Ubuntu).
PCLOS is fine, but tiny less stable in the long run. But it is certainly not bad.
In Ubuntu there is always some little thing wrong and Mint is just a cup better (like WattOS).
Suse less software. Not easy install with multiboot.
Arch is not very cooperative. Too much commandline.
Where there is Debian I prefer Mint LMDE. It is easier.
Fedora with Gnome3...
Etc. etc. etc. much more.
I have seen a lot of distro's with here and there difficulties concerning my demands. So now I now the rest of the story...
I tried Mepis a few times. Not antix. There is always something wrong with Mepis here. So I dropped it. Also because of rather negative reviews on internet. The next will be better, I know.
Another list:
Together with distrowatch it gives a pretty complete total of distro's.
IceWM for me is is too limited because of not much available software. Strong point of wattOS.
Learning Linux is not always easy, but after all it pays off.
Link maybe?
A lot of info.
In the meantime I have tested with all sorts of applications and in daily use on a partition: the 'new' Lubuntu 11.4 (I suspect the base of wattOSR4??) and it is not bad either. Tiny slower. But movable desktop-icons. Everything works, also recording sound (rather important for me). So that will be a fine wattOS4.


text:
Although some parents worry about the sheer number of vaccines babies typically receive, a new U.S. government study finds no evidence that more vaccinations increase the risk of autism. Read more.
The number of American children who suffer from food and skin allergies has increased dramatically in recent years, a new government report shows. Read more.
Here are some tips to get that elusive good night's sleep! Visit our sleep experts at Broward Health Medical Center, Broward Health North, Broward Health Coral Springs and Broward Health Weston.
Follow @BrowardHealth

subset: commoncrawl


text:
Disable bandwidth control by default. Signed-off-by: Peter Zijlstra <firstname.lastname@example.com> --- kernel/sched.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) Index: linux-2.6/kernel/sched.c =================================================================== --- linux-2.6.orig/kernel/sched.c +++ linux-2.6/kernel/sched.c @@ -824,9 +824,9 @@ static __read_mostly int scheduler_runni /* * part of the period that we allow rt tasks to run in us. - * default: 0.95s + * default: inf */ -int sysctl_sched_rt_runtime = 950000; +int sysctl_sched_rt_runtime = -1; static inline u64 global_rt_period(void) { -- --
The fixes look good to me, but this enabling of infinite RT task lockups is not an improvement. The thing is, i got far more bugreports about locked up RT tasks where the lockup was unintentional, than real bugreports about anyone _intending_ for the whole box to come to a grinding halt because a high-prio RT tasks is monopolizing the CPU. In fact there's only been this artificial test so far. So could you please just increase the chunking to 10 seconds or so, from the current 1 second? Anyone locking up the system for more than 10 seconds via an RT task has to deal with many other issues already. I.e. keep the system borderline debuggable (up to 10 seconds delays are _not_ nice so people will notice) - but it's still a marked improvement from completly locked up desktops. And those who really need longer than 10 second periods can set it higher, or even (if they want to live dangerously or run POSIX conformance tests) make it infinite (set it to -1) - and will have to deal with other things like the softlockup watchdog as well. Ok? Ingo --
ok - i've queued the fixes up in tip/sched/rt (not in tip/sched/urgent yet, they need a bit of test-time, but are potential v2.6.27 commits) - see the shortlog below. Ingo ------------------> Ingo Molnar (1): sched: set rt-bandwidth period from 1 second to 10 seconds Peter Zijlstra (5): sched: rt-bandwidth for user grouping interface sched: rt-bandwidth accounting fix sched: rt-bandwidth group disable fixes sched: extract walk_tg_tree() sched: rt-bandwidth fixes kernel/sched.c | 215 +++++++++++++++++++++++++++++------------------------ kernel/sched_rt.c | 16 ++-- kernel/user.c | 4 +- 3 files changed, 129 insertions(+), 106 deletions(-) --
From fc21334298056c1e0d6428d3abe46b104188a05e Mon Sep 17 00:00:00 2001 From: Ingo Molnar <email@example.com> Date: Tue, 19 Aug 2008 13:40:47 +0200 Subject: [PATCH] sched: extract walk_tg_tree(), fix fix: kernel/sched.c: In function '__rt_schedulable': kernel/sched.c:8771: error: implicit declaration of function 'walk_tg_tree' kernel/sched.c:8771: error: 'tg_nop' undeclared (first use in this function) kernel/sched.c:8771: error: (Each undeclared identifier is reported only once kernel/sched.c:8771: error: for each function it appears in.) Signed-off-by: Ingo Molnar <firstname.lastname@example.com> --- kernel/sched.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index 59c6683..10f7ad2 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -1387,7 +1387,7 @@ static inline void dec_cpu_load(struct rq *rq, unsigned long load) update_load_sub(&rq->load, load); } -#if (defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)) || defined(SCHED_RT_GROUP_SCHED) +#if (defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)) || defined(CONFIG_SCHED_RT_GROUP_SCHED) typedef int (*tg_visitor)(struct task_group *, void *); /* --
Why are all these people running poorly written apps then? We don't cater to poorly at the expense of the properly written Nack. Let's retain our API specifications and backwards compatibilty by default. Advertise the sysrq switch and the setting of the sysctl to throttle, but don't break this by default please. --
I agree with you that the 1 second default was a bit too tight - and we should definitely change that (and it's changed already). So changing the "allow RT tasks up to 10 seconds uninterrupted CPU monopolization" is OK to me - it still keeps runaway CPU loops (which are in the vast majority) debuggable, while allowing common-sense RT task usage. But changing that back to the other extreme: "allow lockups by default" is unreasonable IMO - especially in the face of rtlimit that allows unprivileged tasks to gain RT privileges. As an experiment try running a 100% CPU using SCHED_FIFO:99 RT task. It does not result in a usable Linux system - it interacts with too many normal system activities. It is a very, very special mode of operation and anyone using Linux in such a way has to take precautions and has to tune things specially anyway. (has to turn off the softlockup watchdog, has to make sure IO requests do not time out artificially, etc.) You wont even get normal keyboard or console behavior in most cases. Furthermore, if by "API specifications" you mean POSIX - to get a conformant POSIX run one has to change a lot of things on a typical Linux system anyway. APIs and utilities have to be crippled to be "POSIX compliant". In other words: we use common sense when thinking about specifications. The kernel's defaults are about being reasonable by default. I have no _strong_ feelings about it, but i dont see the practical value in going beyond 10 seconds - as it turns a rather useful robustness feature off by default (and keeps it untested, etc.). Ingo --
btw The tuning is actually very easy and straightforward ie not so special anymore. That's one of the use cases that my cpu isolation work was addressing. 2.6.27 will have most of the mechanisms available. All the tuning is done by the 'syspart' package: Same here. I do not mind setting sysctls. At the same time I agree with Nick that ideally we should not change the meaning of SCHED_FIFO. Max --
RT tasks have always been debuggable by using a simple watchdog thread. As I said before, someone who develops a non-trivial RT app without a watchdog thread or isolated CPU basically doesn't deserve the honour of us breaking our API to cater for their idiocity. But even for those people, we now have the sysrq trigger too. And also we'll still have the rt throttle sysctl that can be changed at runtime. There are so many options... "oh but maybe they didn't research the options either so let's break our APIs instead" is not common sense No, it's not "allow lockups by default". It is "follow the API and backwards compatibility by default". If some distro has gone and given all users RTPRIO rlimit by default and allowed unprivileged users to lock up the system, it is not the problem of the upstream kernel. That distro can set the rt throttle default if it wants to. Or provide a watchdog thread for debugging This is exactly what *real* RT app/system developers do. I'm not It's not common sense to change this. It would be perfectly valid to engineer a realtime process that uses a peak of say 90% of the CPU with a 10% margin for safety and other services. Now they only have 5%. Or a realtime app could definitely use the CPU adaptively up to 100% but still unable to tolerate an unexpected preemption. I don't know how you can change this so significantly and be so sure of yourself that you won't break anything (actually you already have one I feel strongly about it. The primary issue is that we have broken the API from both specification and previous implementation, the answer is yes. That *you* can't see any reason to use the API in that way kind of pales in comparison with all due respect. Especially as you already got a counter example of someone's app that broke. --
So... no reply to this? I'm really wondering how it's OK to break documented standards and previous Linux behaviour by default for something that it is trivial to solve in userspace? All the arguments for it IMO are weak, and the argument against is obviously pretty strong but doesn't seem to have been acknolwedged. --
I disagree and what do you mean by "trivial to solve in user-space"? Ingo --
Disagree with what? That it's a problem to basically break the guarantee I mean that if some distro has turned on the RT scheduling ulimit by default and now finds themselves with a local DoS for unpriviliged users as a result, then either that distro should just make their init scripts set the throttle and break the API themselves, or they should start a watchdog at a higher priority than unprivileged user can set. --
I think you are sticking to the rigid letter of some standard without seeing the bigger picture. Firstly, please realize that to do a "successful" POSIX or other conformance run a default Linux distribution has to be tweaked and often crippled literally dozens and often hundreds of ways. In this case you also have to add one more entry to /etc/sysctl.conf, to allow RT tasks to monopolize CPU time. So you can still get the POSIX sticker if you want to - nothing changed about that. Secondly, my big picture point is that our task is to make Linux more useful and more usable by default. You seem to be arguing that RT tasks should be allowed by default to monopolize all CPU time forever, and i disagree with that proposition. But do _you_ actually use such runaway CPU-monopolizing RT tasks? Try it one day and you'll quickly meet various practical problems. Let a SCHED_FIFO:99 RT task run long enough and on all the main distributions you will get: BUG: soft lockup - CPU#1 stuck for 61s! [bash:3659] But monopolizing any resource in a 100% way (which you are arguing for) is just not a generic Linux system and for years (seeing all the practical problems with it) we tried various methods to contain SCHED_FIFO tasks in the scheduler, none was really acceptable for mainline. Peter's changes were clean and useful at last. There's lots of apps that use SCHED_FIFO for a short burst of activity, and 100% of the ones i know do not want to run for longer than 10 seconds. Thirdly, your argument can only be consistent if you also argue for the ... but that's by far not the only usecase. Very frequently i've seen bugreports from people with runaway RT tasks (which tasks were running as root) where that runaway behavior was completely unintended. Audio apps or other apps getting into a loop and locking up the system. Worse than that, such bugs prevented the system from being debugged by plain users. A runaway RT task that monopolizes the CPU will lock it ...
I'm not talking about anything else except this particular interface. I'm also not talking about getting a sticker or anything, but providing Then that's not SCHED_FIFO/SCHED_RT, so just make another scheduling class. SCHED_FIFO and SCHED_RT can use up all CPU time, but that's why they are privileged by default. root has always been able to do silly things, that's nothing new. It is the easiest thing in the world to have made a new scheduling class Again, I'm talking about the upstream kernel, and I'm not actually interested in other bugs or problems because the way to fix things is to solve one bug at a time and not give up just because there are some other bugs. Soft lockup message I don't think causes much pain, except it may be useful to actually panic and do failover with but AFAIKS it is not enabled by default Actually you can pretty well isolate kernel services and interrupts from one CPU and run rt tasks on that. But anyway, who are you to impose a magical And how is that a kernel problem? Should we fix the kernel against Tell the stupid audio program writers to run a watchdog task if they are running a non-trivial amount of code with rt sched policy. Like any Privileged users can break the kernel and kill everyone so easily anyway, Somebody already reported their app failed with 1s. What makes you think there are none around that fail with 10s? Changing old existing userspace APIs can't be done just because a single person (you) can't think of a counter example. Especially not when it could equally be done just by introducing a new No, what's not nice is to subtly change behaviour in a way that's not I disagree. And given the amount of dual core CPUs around these days, I suspect you exaggerate the number of bug reports you get about this too. But anyway as I said, if you're enabling rt prio ulimit by default in your distro and then dislike the local DoS it opens up, then why can't you also just change the rt throttle yourself rather than ...
Your arguments were along the line of: * It probably doesn't break anything (except we had somebody report that it breaks their app) * If it does break something then they must be doing something stupid (I refuted that because there are several legitimate ways to use rt scheduling that is broken by this) * We have many other APIs and tools that don't conform to posix (why is that a reason to break this one?) * We should break the API to cater for stupid users and distros who create local DoS and/or lock up their boxes (except this is trivial to solve by setting sysctls or having a watchdog or using sysrq) So did I miss some really good argument, or do you really think the above arguments are a good reason to break the API? If the latter, then we have to just agree to disagree and I'll ask Linus to arbitrate. OK? --
I'm a real-time oldtimer. An application which hogs the CPU for 9.9 seconds with SCHED_FIFO priority is just broken. It's broken beyond all limits, whether POSIX allows to do that or Linux obeyed the Simply because we use common sense instead of following every single For the vast majority of users and RT developers a sane default of sanity measures is useful and sensible. If someone wants to shoot himself in the foot then it's not an unreasonable request that he needs to disable the safety guards before pulling the trigger. Thanks, tglx --
Oh with this much handwaving from you old timers I feel much better about it ;) I bet before the bug report and change to 10s, any application that hogged the CPU for more than 0.9 seconds was just broken too, right? But 10s is more than enough for everybody? I may not be an old timer, but I can say the kernel is just broken if it deliberately deviates from standards to undocumented behaviour, and even more so if it changes from working to broken behaviour for reasons that can be worked around in userspace (eg. running a higher How is that a brainfart? It is simple, relatively unambiguous, and not arbitrary. You really say the POSIX specified behaviour is "a brainfart", but adding an arbitrary 10s throttle "but the process might be preempted and lose the CPU to a lower priority task if it uses 10s of consecutive You seriously develop complex rt tasks without having at least a simple root is allowed to shoot themselves in the foot. root is the safeguard. --
Actually, any real-time application which hogs the CPU at a high real-time priority for more than one second is probably doing something broken. The whole point of high real-time priorities is to do something really fast, get in and get out. Usually such routines are measured in milliseconds or microseconds. Think about it *this* way --- what would you think of some device driver which hogged an interrupt for a full second, never mind 10 seconds. You'd say it was broken, right? Now consider that a high real-time priority thread might be running at a higher priority than We've not followed POSIX before when it hasn't made sense. For example, "df" and "du" report its output in kilobytes, instead of 512 We've done things before to make things harder for root; for example we've restricted what /dev/mem can do. And root can always lift the ulimit. - Ted --
Sorry, the world of embedded programming is sometime stranger than in theory. Normally it would not happen that a real-time process locks the CPU for more than 1 sec. But in some circumstances, especially FPGA initialisation and long term measurements it is possible that the real-time process locks the cpu for more than a, sometime for more than 10 sec. If the embedded program has designed it in that way, this This has nothing to do with POSIX. It is standard real time behaviour. RT Programming is a job like writing device drivers. U must know what you do. Modify the scheduler in that way that a realtime process will give away the CPU after a given time will certain break some embedded application. Don't think only in desktop or enterprise LINUX boxes, there a much more LINUX embedded devices on this planet and not less of them rely on the old scheduler behaviour. The LINUX base guideline is simple in that way, that the kernel will What coming at next? A device driver manager, which kills any driver which use to much CPU resource? Or throttle/kicks off the responsible driver if the hardware generates to many interrupts? Kernel and embedded real time programmer should know what there do. Stefani --
And if that's true, the embedded program can adjust the ulimit to change the priority levels as appropriately. Real-time programming will always required a bit more configuration, such as what priority various hard and soft interrupt routines will run it. This is just Actually, we have both of these already. :-) - Ted --
Well, we might have a public opinion poll, whether a system is declared frozen after 1, 10 or 100 seconds. Even a one second unresponsivness shows up on the kernel bugzilla and you request that unlimited unresponsivness w/o a chance to debug it is the sane default. An one second RT CPU hog is just a broken application, nothing else. Your precious customer use case is simply crap. Real-time is about determinism and not about the allowance to fuck up a system at will. If a system failed to prevent the fuckup once then this is not at all a guarantee that it allows to do that forever. Especially not in the Open Source space, where developers are still allowed to use their brain and apply common sense to prevent such a wreckage and abuse. Still, your not yet specified use case can continue to do stupid things forever with the simple tweak that it needs to declare itself broken by turning off the kernel sanity Right. I appreciate the nitpicking janitor of the most important POSIX feature: "The unlimited right to monopolize the CPU for any given timeframe." Get your brain together. Just because it worked before and POSIX allows it is not an argument at all that it is something useful. If you want to do this you still can do it by resetting the limit. Your request to enforce that stupid and braindead behaviour on No, I did not say that. All I said is that giving the normal and common sense capable user/developer the chance to debug a runaway task w/o rebooting the system via the power off button is a sensible and useful default. Your request to default to a possibly unusable system serves some yet to be explained higher goal, which is definitely out of the scope of common sense. You still did not explain why this behaviour is useful and your handwaving vs. some (probably closed source) customer application is Dude, don't tell me how to design and debug a real time system. It's not about me, but about the general usability and debuggability of Linux even in ...
That assumes single CPU. With multiple CPUs and not all hogged the system should be still responsive? -Andi --
Right. But also it assumes desktop/general purpose server thing. There may not even be any user interface to be unresponsive. Or it may be something implemented with a userspace driven scheduling system. Or an event loop in a single process. --
Wrong. Even if the system has multiple CPUs, and even if just a single CPU is fully utilized by an RT task, without the rt-limit the system will still lock up in practice due to various other factors: workqueues and tasks being 'stuck' on CPUs that host an RT hog. While there's obviously CPU time available on other CPUs, you cannot run 'top', the desktop will freeze, work flows of the system can be stuck, etc, etc.. With the rt limit in place, it's all pretty smooth and debuggable. Even with all CPUs hogged by SCHED_FIFO prio 99 the system is laggy but debuggable - the user can run 'top' and can resolve the situation. Really, this reply of yours shows something startling: that despite this many mails you still have never actually tried to run the scenario you are complaining about: you have never tried to run a CPU hog high-prio RT task on a Linux system before, and you have never observed the effects it has on general system stability and debuggability. This fundamental lack of experience weakens all your arguments and i dont even know why you are arguing about it. Do you perhaps have some customer application/workload you are worried about? If you have then please tell us about the exact specifics - this handwaving about compliance really makes little sense. In other words: in our car the air-bag continues to be enabled by default, and if someone wants to use the car for stunts the air-bag can be disabled via that handy sysctl. In any case i think i'm going to ignore this thread from now on, nothing new has been said really, just the general tone of discussion is deteriorating. You are also very late with raising objections in any case - the rt-limit feature has been posted 10 months ago and went upstream 8 months ago - two full kernel cycles have been completed with this change in place and a third one has almost been finished. Ingo --
The load balancer will not notice that a particular CPU is busy I had such a situation at least once in the past (not due run away RT but due a kernel bug) and even with 2 out of 4 CPUs blocked the system was still quite usable. top/kill definitely worked. The system didn't have a desktop, but I didn't notice many problems in shell use. Ok it's just one sample. That said I don't think having such a limit by default is a bad idea actually. Just handling it in the scheduler anyways is also probably good because it can happen even due to other issues than just run away RT tasks. -Andi --
Not currently, working on that though. --
yeah, that's nice - i tried the earlier iteration of your patch already. It doesnt solve the UP case obviously, nor the case where all CPUs are hogged by RT tasks, nor any other (or future) per CPU aspect of Linux that we have in place currently. Ingo --
I wonder if it would make sense to break affinities in extreme case? With that even the workqueues would work again. -Andi -- email@example.com --
Then people can no longer assume stuff like queue_work_on() etc.. works. Users of such code might depend on it actually running on the specified cpu. --
If they assume that they're already buggy because CPU hot unplug will break affinities. -Andi --
It is actually possible (with fairly little work, last time I looked, maybe it is already integrated in the kernel) to avoid all this kind of thing from isolated CPUs. But even then, note that the types of programs using the CPU for long periods are obviously not going to be run on an average desktop system. So the responsiveness argument is laughable. Responsive as defined how? And in relation to what type of systems? --
Please lets not break affinity :). I'm going to submit patches (soonish) that convert drivers/etc to use cancel_work_sync()/flush_work() instead of flush_scheduled_work(). That takes care of the "machine getting stuck because workqueue thread is starved" case. Max --
correct, breaking affinity is a rather stupid idea. Ingo --
Ok let's remove cpu hotunplug then. Probably nobody uses it anyways @) Seriously cpu affinity on all non BP CPU is currently broken on every suspend to RAM, doing it in a few more cases when it makes the system more robust is unlikely to hurt anybody. -Andi -- firstname.lastname@example.com --
No, it is right. With caveats. Because you can pretty well isolate a CPU from running kernel threads or work. At any rate, I don't think it When I write rt apps, I run a watchdog thread which detects a hang Of course I have and of course I know what it does if you run a for (;;) rt thread on an ordinary Linux desktop system. Trying to You're continually ignoring all of my arguments and instead raising irrelvant things like this. You ignored others in this thread who replied with real uses of the rt scheduling that is being prevented by this API breakage, and you're ignoring my examples of how it could be used and just keep asserting that "anybody who does that is broken anyway". You also ignored when I told you how you can fix this correctly by introducing new SCHED_xxx scheduling policies that won't break backwards compatibility and will be defined from the outset to be throttled as such. There is no customer issue and there is no handwaving about compliance; it is a black and white issue: this behaviour breaks all documentation, How am I supposed to respond to that? My car doesn't have an air bag but it's breaks don't stop working every 10 seconds. OK, if you don't wish to have further discussion then I will submit a So what? --
well, the reason i'm asking is that i cannot for anything in the world imagine you being so upset about _anything_ but something that involves benchmark runs ;-) And what does SCHED_FIFO RT policy scheduling have to do with performance and benchmarks? Nothing usually in the real world, except for this little known fact: a common 'tuning' for TPC database benchmarks is to run all DB threads as SCHED_FIFO to squeeze the last 0.1% of performance out of the setup. So - and i'm taking an educated guess here - is SCHED_FIFO+TPC performance perhaps one of the factors that played a role in you initiating this thread? If yes then it's obviously an incredibly broken use of SCHED_FIFO and we can add the sysctl tuning to the long list of dozens of other tunings that happen before a TPC run anyway. Hm? Ingo --
;) Well yes as you know I'm not actively doing much scheduler work for a while now. Luckily there are a lot of really good people who probably do a better job on it than me anyway, so on the whole I'm quite happy with it. But ironically that's also why I hadn't raised my concerns earlier... I simply was not aware of the change. So I wish I had participated in the To address this concern: no, it is not tpc ;) Actually I don't know a thing about how tpc except what scant information can basically be gained on the list (disclaimer: I probably could find out more under NDA, but I don't care to). No, there is no customer behind the scenes and nor do I have a use case myself. I really would have told you about it by now. I'm concerned because I honestly think there is a risk of breaking systems. I also think that in this problem space, people often care about guard bands and worst case scenarios so even if the app does not do a cpu hogging polling loop or cooperative scheduling or anything like that, then I think it is risky to add this source of uncertianty. The other issue is that the old behaviour (and, dare I say it, specification) is quite straightforward. At least it is simpler and thus I guess easier to analyze than this behaviour with the added caveat. I realise that as Linux gets better at this, people are wanting to use -rt programs like audio mixing on their desktops and for that kind of thing, throttling is probably often the desired behaviour. So I can see why it was implemented. I just think it is a nasty surprise to have this behaviour by default in the kernel. I hope I explained myself better now. I was not being too constructive when I was getting heated. What I would like to see is maybe a new SCHED_ policy or two which can be defined basically as rt-with-throttle which some apps could use. I also think the sysctl to throttle it is a fine idea. And for desktop installations there is probably a much stronger argument for it. But I disagree with ...
BTW. this is funny that you just decide you can somehow "weaken" my technical arguments because of some of my personal attribute you believe about me. You don't know why I am arguing? I'll put it very simply one more time. - This behaviour has changed the kernel's userspace API in a way that can break existing applications. That is my primary point. If you think it gets somehow weaker because you don't think I have ever locked up my workstation with an RT task, then I give up arguing with you. --
I don't understand the fixation on declaring a system frozen. I repeat: how do you know "rt task code that hogs the CPU for 10s is broken"? This still hasn't been adequately explained to me, and from responses to this What customer use case are you talking about? I never mentioned one and have none. Are you confusing me with someone else? But OK, so if someone else has a customer use case that breaks, what makes you think you can just declare it is crap and we don't care about it? For that matter, what has closed source got to do with it? We don't This is just handwaving and ignoring the issue at hand. SCHED_FIFO and SCHED_RT are exactly about being able to hog the CPU. That is exactly Huh? Again, I don't have a use case, and even ignoring the several posts of people who do, I would still make the same argument because it is plain for me to see that breaking the API by default is the wrong thing Umm... yeah. That's exactly one of the important properties of SCHED_FIFO I don't deny that the runaway task thing is a *small* advantage. But You have it completely backwards. If someone wants to change a userspace API, it is *they* who must not handwave about why "anybody who wants to do that is broken anyway so we don't care about them". I, on the other hand, opposing the API change, sure can handwave or find one or two counter examples as to why we might have users relying on the old behaviour. The replies you got might convince you that your view of the rt world is not the complete and only picture. But if not, then consider that rt tasks need not have a fixed amount of work to be done per unit of time but they may scale work according to the available CPU power. Or it may be something I didn't tell you, I asked you. Do you develop without a watchdog? Do you think the majority of RT developers do? Because if so, then I certianly will tell you to use a watchdog to get the debuggability you ask for, rather than break the kernel interface for everyone else.. ...
Well, I've been working on RT hardware (mostly) and software since 1977. With all due respect, thats crapola. I for one have this requirement and there is _no_ way around it in my world. In fact it's the kernel thats broke by stealing precious usecs from me. From my point of view, as an RT user, any kernel that supports SMP yet can't Again that is also crapola. If i want to shoot myself in the foot, it's none of your concern. I know perfectly well what will happen when I pull the trigger. My 2 cents Regards Mark --
I'm sorry, but I need to agree with this. I've been focused more on RT and in military apps since 1991 (not as long as 77 though :-) There's two issues here. 1) What FIFO means 2) Protecting the 99% of the users What most real RT centric folks will want is the true meaning of FIFO. That is, a FIFO task can run as long as it wants using as much CPU as it wants until a) a higher RT task preempts it, or b) it voluntarily releases the CPU. This change, without doubt, breaks the definition of what a FIFO task is. This is the kernel imposing policy onto userspace. What Thomas Gleixner and Ingo Molnar are doing, is focusing on 2 above. (protecting the 99% of users). This is reasonable, since thats who will bug them the most when things break. The problem I have, is that this is breaking a defined user API. A default that is well known within the RT community. The simple definition of FIFO. What I would suggest is this. 1) Keep the default as the infinite for those that know what they are doing. 2) Change the sysctl scripts in the distros to set the default to a sane time that will protect the users. An RT app that would break the 10s limit would probably be using busybox anyway, so the default for that would be what the kernel comes up with. The default the 99% of users would have, is what the distro set it to for them. This seems like a sane solution to satisfy both camps. -- Steve --
Makes sense to me. It could even get sent out to users about as fast as a new kernel by itself, since they could just add a package dependency to update the init scripts when the end-user installs the new kernel package. Anyone messing with the kernel directly is likely 1) smart enough to deal with existing FIFO semantics, and 2) able to modify their own init scripts to get some additional security if they so desire. Chris --
My biggest concern about adding a limit to FIFO is that an RT developer would spend weeks trying to debug their system wondering why their planned CPU RT hog, is being preempted by a non-RT task. For this, if this time limit does kick in, we should at the very least print something out to let the user know this happened. After all, this is more of a safety net anyway, and if we are hitting the limit, the user should be notified. Perhaps even tell the user that if this behaviour is expected, to up the sysctl <var> by more. Peter, another question. Is this limit for a single RT task running, or all RT tasks. I'm assuming here that it is a single RT task. If you have 20 RT tasks all running, would this let non RT tasks in? In that case, this could be even a bigger issues. Thanks, -- Steve --
yeah, agreed, this is a reasonable suggestion. Peter, do you agree? Ingo --
Seems reasonable. But I still think it should be disabled by default (it might not get caught in testing for example). --
Perhaps we should default it to 1sec, that way it would be hit more often, and educate the users of this now feature. -- Steve --
There only one sane default, as far as I can see. Before anybody attacks me again because I haven't got my brain together or am an annoying standards nitpicker: I'm very well aware of the consequences of unlimited hogging of the CPU. And I know exactly why people might want rt throttling. But just think for a minute the _negative_ consequences of changing the API and remember that is close to the #1 rule of Linux development to not break user API. And put it this way: the sysctl is right there. Any distro that cares about this problem will probably find this thread as #1 hit and work out how to enable the sysctl and break the API if they are happy to do that. On the flip side, not every application development or deployment is even going to know about this, and it may not be trivial to catch in testing, so it could cause failures in the field. --
The issue here is where to place the policy of protecting the user. Is it in the kernel, or is it up to the distro. I've always thought that the policy settings belong in the distro, and the kernel should never enforce a policy (by setting this as default, it is enforcing a policy, even though an RT user can change it). I've recently been told that the kernel has of recent, has indeed been starting to set policies. With protection of memory and such. If this is the case, that the kernel is the place to implement policy, then the "sane" default belongs there. If the distro is the place to instill policy, then that is the place to put the "sane" default. Basically, I'm not in a position to say where Linux should place the default policies (distro or kernel). I've always thought the kernel should be bare bones, allowing the distros to do all the policy settings, and those that compile and build their own kernels/distros do so at their own risks. But if this is no longer the case, then who am I to argue. I guess this decision belongs to those above (Linus, Andrew)? -- Steve --
The kernel has always done a certain amount of "default policy". What do you think things like "swappiness" etc are? Or things like oevrcommit settings? They're all policies, and there is always a default one. So in that sense the kernel always has - and fundamentally _must_ - set some kind of policy. And the default policy should generally be the one that makes sense for most people. Quite frankly, if it's an issue where all normal distros would basically be expected to set a value, then that value should _be_ the default policy, and none of the normal distros should ever need to worry. Whether this case is one such, I dunno. Quite frankly, I don't think it's even _nearly_ important enough to get this kind of noise. Linus --
I guess the reason that this is getting so much noise over other default policies, is that this default policy is changing a well known definition: The meaning of FIFO. By making the default policy limit the time an RT task runs, we have, in essence, changed a user API. Applications that expect to be able to run uninterrupted by SCHED_OTHER tasks, will now break. No one is arguing that this new feature is not useful. The argument is, should the kernel set the default policy of an old well known scheduling policy to something different than what is expected? Distros set SE Linux on by default, should the kernel do that too? -- Steve --
A lot of people I have an immense amount of respect for with vastly differing opinions. There was mention of a user poll so I'll share my .000000002 USD here. I have accepted in my dealings with real-time that it is a special programming paradigm. The developer has much greater control and must exercise it responsibly. From this, I have accepted that I can bring my system to it's knees rather easily if I'm not careful. I agree with Nick and Max that this default behavior should be preserved. I like Steven's suggested of disabling the throttling in the upstream kernel, and leaving it to the distros to safe-gaurd the user from themselves should they choose to. There is already some precedent for this with the updated default kernel thread priorities and realtime group and pam limits.conf settings in Red Hat's MRG product. When doing real-time application development, I use various mechanisms to ensure debugability, and it varies based on what I'm doing and how I access the machine. Sometimes I need special watchdog application, sometimes I need to boost all the kernel threads related to networking or serial consoles and the respective login apps (ssh, agetty, etc.). It seems reasonable to consider this throttling as another _optional_ tool in my debugging toolkit. -- Darren Hart --
More and more are wanting and now finding the Linux kernel to be more RT capable. I seem to remember way back you saying it was one thing you didn't really care much about one way or the other. Thats OK. But, you _are_ the man. Put an end to this. Are you going to allow the long understood meaning of SCHED_FIFO to change in the Linux kernel just to protect a few _supposedly_ bad programmers??? Regards Mark --
The thing is, the reason I dislike RT is that so many people have so different understanding of what RT means. Quite frankly, I think that the people who are complaining (like you) think that RT means "hard realtime". You think about literally specialized devices. A lot of _other_ people think that RT means "good audio latency", where it really is a lot softer. And neither camp seems to ever admit that they are just a small camp, and that the other camp exists or is even valid. And I'm not really interested. Quite frankly, I suspect the "we want to run something like pulseaudio with RT priorities" camp is the more common one, and in that context I understand limiting SCHED_FIFO sounds perfectly understandable. quite frankly, most programmers aren't "supposedly bad". And if you think that the hard-RT "real man" programmers aren't bad, I really have nothing to say. Linus --
The fact that it actually limits a SCHED_FIFO task group, over a single task thread does bother me a little. But that said, I and others have made our complaints known, and will forever be documented in the halls of the Internet abyss. Thus, the verdict has been laid. Seems the default shall be something other than infinite. I will now remain silent. -- Steve --
It bothers me some too. You have to patch/re-compile the kernel if you need to turn it off and don't have SCHED_DEBUG enabled (not free). I tripped over this recently while regression testing. I didn't expect a gaggle of SCHED_RR tasks to be throttled on an otherwise idle box. Hitting that perturbed test results in an unexpected manner, and sent me off on a tangent. -Mike --
/proc/sys/kernel/sched_rt_{runtime,period}_us don't require SCHED_DEBUG. If they are in any way non-functional on SCHED_DEBUG=n then that's a clear bug. --
Gee, you're right. I guess my eyeballs didn't want to see them without their friends. -Mike --
I started this discussion last week with an apparent bug in the new CFS. As it turns out, it was not a bug, it was an feature, a (undocumented?) feature. In the world of embeded device and real time programming it is not a hard job to compile the kernel right for the desired usage und fix the startup script to use the desired policy. Getting back the old behaviour would be nice and in my opinion the right way, because the new one breaks with POSIX. But I have a working solution and that is for me what matters. By the way - RT means not hard real time. Hard-RT is a marketing phrase. A given combination of OS and hardware must handle a event in a given time. Thats all. Thanks for the support. Regards, Stefani, the hard RT "real woman" programmer ;-) --
Is there actually a reason we can't have two forms of SCHED_FIFO. For hard RT the existing behaviour is a lot more useful and it is hard to see "real man" programmers stare at the code in Zen contemplation and debug by powercycling - thats one thing even hard RT processes can't beat. Alan --
There is a difference. You *have* to pick some value for those things. The settings can't necessarily be called correct or incorrect. The default rt sched policy is definitely "broken" in that it very clearly changes our previous behaviour, documentation, and what other systems do. You could say that "realtime" in general is not really a single accepted definition, but *SCHED_FIFO* and *SCHED_RR* in particular do have a well defined, simple, and widely accepted definition that is undeniably changed by this "policy". Given that a) we can easily introduce new SCHED_xxx policies to implement the new behaviour, and b) there are quite a few users of this API in this thread who are concerned about the change, I think it is wisest just to revert to our old behaviour. I thought the rule of thumb is "if in doubt, we don't break user APIs". It's funny that nobody has really answered any of my points of concern. That's cause you don't care about rt that much. You do care about back compatibility though so I thought you'd be more interested. Anyway, I won't post any more. --
I cannot believe you guys are still arguing about this and calling each other stupid/incompetent/braindead and such (not this particular email but all the stuff before) :) Seems to me like leaving RT throttling disabled by default is a reasonable compromise. Several people suggested that and the advantage is that it does not change the definition of SCHED_FIFO/RR by default. I personally do not care that much what the default is. If Fedora, for example, starts enabling it by default I'll still have to change it. So it's not much different from enabled by default in the kernel. Max --
I'm rather surprised at this whole conversation. I think it is pretty simple that. 1. The kernel should not set policy but provide capabilities. a.) It would be more appropriate for a distro to set the policy -. but even here, the default policy should match the expectation of what SCHED_FIFO is and standards such as POSIX unless there is a really really good reason to show why the standard is wrong. (and I haven't heard it here) b.) The fact that it is possible to change the settings is an excellent feature, but that cannot be used as an argument to change the default settings to something unexpected. Rather, the feature can be used to change what the standard default is. 2. SCHED_FIFO doesn't have limitations to it, even if the application programmer can abuse it. That to me seems to be the whole purpose of SCHED_FIFO - it does let you do things if you have the proper privileges that a standard kernel protects against, but if the kernel sets a limitation on it, then it simply isn't SCHED_FIFO anymore, it's something else. I really dislike this talk about what a good application programmer should do anyway, I like that we can be surprised at human creativity and how things can be used in unexpected ways, so I don't see why that should be throttled. And this argument about false kernel lock-ups seems bogus to me too. John --
No its not per task. Its per group (and trivially the !group case is one group). All this bandwidth code comes from RT group scheduling. We do that by assigning a bandwidth to each group so that within that bandwidth each group can use RT tasks and have them behave like they should. I don't fully agree with the statement that the most important thing for SCHED_FIFO is to run as long as you want. The most important thing SCHED_FIFO brings us are deterministic scheduling rules. And RT group scheduling maintains that determinism by using a constand bandwidth assignment. Now the thing that we've been bickering about - bandwidth limits on the root group, which just fell out of the whole ordeal due to symmertry. On the one hand, a program that ran deterministic will still run deterministically at n% (although of course, just like running on less powerfull hardware, you could miss deadlines you previously did not). On the other hand, people might not expect that. Having a lower than 100% bandwidth limit by default gives a safer environment because it avoids total starvation, nor does it take away determinism [*]. It does however bring the risk of surprising a few folks. [*] - there is some added jitter due to the throttling logic, and since the default period might not align nicely with actual deadlines its not perfect. An EDF based scheduler with <100% bandwidth caps would do better. Other scheduling classes have been mentioned... I've been on the point of writing SCHED_ISO, a bandwidth throttled SCHED_FIFO that doesn't require root priviligles and comes with say a 10% bandwidth limit. Doing that should not be too hard - it will just add more code and a bigger configuration space. --
Does this mean, if I have 100 RT tasks, that will together run for 10secs secs, they will only run for 9.5secs? This looks like an even bigger issue. Now we don't have one RT FIFO CPU hog, we are now hitting 100 RT FIFO tasks that try to get a bunch done in 10 secs. -- Steve --
Yes. But say you were doing rate monotonic scheduling (as is not uncommonly done on top of SCHED_FIFO) then you could not get 100% cpu utilisation anyway, as RMS has a ~69% utility bound. --


text:
If it were up to me, any anti-Apple trolls would not be allowed on this forum and any violators would be banned for life (one strike and you're out!). Hell, if it were up to me, people would not be allowed to access this forum, unless they were on a Mac or iOS device. I don't come here for discussions with anti-Apple people, as I am not interested in anything that these people have to say. I am only interested in speaking with fellow Apple users. But that of course is not up to me, so all I can do as a user is to forcibly knock down any ignorant comments which anti-Apple people spew from their mouths. As opposed to what some other people might believe, I don't believe that ignoring ignorance is the best method for dealing with trolls. I believe that they should be confronted head on and killed as quickly as possible
I'm a little late to this thread but what the hey.
I like your style, Apple][. Sure, every child deserves to play in the local sandbox, but if some little dude decides he's going to use it as a toilet, I say, send him thither and yon.
You do rant a little too Apple-supportive at times, but hey, if a guy loves the gal he loves, why can't he occasionally go waggly-eyed over her attributes. So someone else thinks she's a hound snack, well, some thoughts should be kept in one's head.


text:
FULL RESOLUTION - 1000x1166
News » Published 17 weeks ago
Is this Joaquin Phoenix the Actor?
Share your thoughts on this image?
Related Celebrity: Actor - Joaquin Phoenix
25th January 2013 @ 01:08am
Joaquin Phoenix is in line to star in the Paul Thomas Anderson movie Inherent Vice
21st January 2013 @ 11:31pm
Joaquin Phoenix makes a joke about Daniel Day-Lewis when accepting his Best Actor award at the London Critics Choice Awards
14th November 2012 @ 08:16am
Joaquin Phoenix takes back his earlier comments insulting the Oscars


text:
Participate in this Event or find another event
Greer High School
3000 County Road 96, Greer Map it
Already a participant?
Log in here
51 teams and 395 participants have raised $122,932.55
Total above may not reflect all donations
Monday, May 13, 2013
BBT of Greer
400 Memorial Drive, Greer SC
5:00 pm - 7:00 pm
(enter from SSI side)
Tuesday, May 14, 2013
Greer High School
6:00 pm
ALL team captains are encouraged to attend!
For more information, please check out our Announcements tab, like us on Facebook (www.facebook.com/RelayForLifeOfGreerSC), or follow us on Twitter (RelayGreerSC).
Finish the Fight....Now is not the time to be silent!
The journey to end cancer starts with a single step. The American Cancer Society invites you to take that step with us by joining the global Relay For Life movement. When you walk to end cancer at a Relay event, it's your opportunity to not only honor cancer survivors and remember loved ones lost, but also to raise awareness about what we can do to stay well from cancer and raise money to help fuel the world's largest walk to end cancer.
Event sponsored by:
Top Participants:
Top Teams:
Top Companies:


text:
The following criminal cases were resolved last week with the use of plea agreements:
•Tiffany Rose LeMarr- six counts forgery, six counts theft under $500; six years probation, court costs, $450 to ECF, $747.42 restitution to victims.
•Joshua C. Leffel- theft over $1,000; split confinement of 32 days with a jail credit since Aug. 5, four years probation, court costs, $75 to ECF, $936 restitution to victims.
If you currently subscribe or have subscribed in the past to the Lafollette Press, then simply find your account number on your mailing label and enter it below.
Click the question mark below to see where your account ID appears on your mailing label.
If you are new to the award winning Lafollette Press and wish to get a subscription or simply gain access to our online content then please enter your ZIP code below and continue to setup your account.
ZIP Code: | |


text:
- Highlights
Manufacturer's SKU 781 Shipping Disclaimer Ships Within 3-5 Business Days Manufacturer's Warranty Manufacturer defects - practical lifetime of product Why We Like It We like Granite Gear because of their dedication to high quality innovation. Granite Gear sets the standard for durability, portability and accessibility. These guys are serious about quality and design and have a passion for innovation. Brands Granite Gear - Description
The H2 H.O. is the perfect way to tote your CamelBak or Source bladder (not included), especially if you prefer the High Output Underarm Tube Routing and like to keep your water insulated. Can be laced onto your vest, or use the webbing as shoulder straps.
Features- Weight: 2.0kg | 4lbs 8oz
- Holds 100 Oz Or 3 Liter Hydration Bladders (Not Included)
- Closed Cell Foam Insulation
- 500 D Cordura Nylon
- Pals Webbing Throughout
- High Output Hydration Ports Located At Bottom (Left & Right Sides)
- Internal And External Zip Pockets
- Quick Release Shoulder Straps
- Haul Loop
- Ideal Tac Zipper
- NIR Enhanced Concealment
- Reviews
Write Your Own Review
- Product Tags


text:
What people are saying - Write a reviewUser ratings
Good overview, but better used for pictures. - Goodreads Definitely a good reference to start with. - Goodreads Excellent pictures and descriptions. - Goodreads Lots of info for the moneyUser Review - servantofgod4 - Christianbook.comWe are studying insects in science. My 4 year old found a caterpillar in the book that we had seen a week before I received the book. It is that easy to use. My 6 & 13 year olds love using this book ... Read full review Review: National Audubon Society Field Guide to North American Insects and Spiders (National Audubon Society Field Guides)User Review - Becca - GoodreadsGreat pictures and information, though it seemed like they could have added more insect species. Read full review Related booksContents
1 other sections not shown Other editions - View allCommon terms and phrasesabdomen abdominal segment Adult drinks nectar Adult eats Adults emerge antennae aphids areas bands bark bees beetles body British Columbia brownish bugs burrow butterflies Caterpillar Caterpillar eats Caterpillar feeds cells cephalothorax chelicerae cocoons color compound eyes Cycle damselflies dark brown Deciduous Description Eggs are laid elongate elytra Family female female's femora flies Flight Florida flowers foliage Food fore wings forests genus Grasshopper gray grayish green Habitat hair hatch head hind wings juices Larva feeds legs Male Male's mate Meadows Mexico moths mouthparts Naiad nest North America Nymphs orange oval overwinter ovipositor pair pale parasites pedipalps plant stems plants pollen predators prey pronotum prothorax pupate Range reddish brown resemble side slender small insects soil South southern Canada species spiders spines spring stripes Texas thorax Throughout North America tibiae trees twigs usually veins Vs�Vi Vs�Vs wasps wingless Wings clear Wingspan wood yellow yellowish Bibliographic information |


text:
If you registered for membership in the past 10 days, please reregister. I'm certain I accidentally deleted you when I was pruning the membership lists yesterday.
0 Members and 1 Guest are viewing this topic.
She doesn't go as far as to say that buying me Gift X means we won't be able to afford Necessity Y, but she's been known to complain a blue streak about the price of everything from school tuition to salad dressing, and then in the next breath, she'll say something like, "Oh, by the way, Freaky, just warning you, there'll be men coming over to paint the kitchen/re-shingle the roof/re-gild the driveway next week."
Quote from: freakyfemme on December 18, 2006, 04:56:58 PMShe doesn't go as far as to say that buying me Gift X means we won't be able to afford Necessity Y, but she's been known to complain a blue streak about the price of everything from school tuition to salad dressing, and then in the next breath, she'll say something like, "Oh, by the way, Freaky, just warning you, there'll be men coming over to paint the kitchen/re-shingle the roof/re-gild the driveway next week."Her money, her priorities. It's not nice to turn around and tell someone their priorities are out of whack. Is it possible she's asking for appreciation? Then again, some people just complain.
Of course I appreciate what my parents do for me.
......it's just incongruous when my mom pays hundreds upon hundreds of dollars for the frivolous home-improvement project of the minute, or buys extravagant gifts at Christmas time, or lavishes me and my brother with care packages of useless trinkets during the school year (fuzzy blue Easter bunny ears, anyone?); and then pitches a fit about paying $3.99 for a bottle of salad dressing.
freakyfemme, I'm disappointed that you don't have a hilarious retort for anyone who would be so rude as to comment like that on your jewelry, lol. Wait, promise me that you do, but actually saying it would be rude, right? Right? Don't make me lose the faith! <wink>It's possible that you're worrying a little too much about it, *but* I think I also understand where you're coming from. When I was little (about 6 or so), several girls from our congregation came over to play. The following week, one girl's mother informed my parents that I had far too many toys and "name-brand" items, and she would no longer allow her family (some of the girls were cousins) to play at our house or associate with me. So I was out of the clique until we switched congregations many years later. Some people are just self-righteous and you will make yourself miserable trying to make them comfortable. Next, shame on your brother for ruining the surprise and for trying to make you look greedy. And, in reading all of the posts, I don't think there is really anything you can do with your mom, except thank her profusely for what will become a great heirloom item.
"It's a gift" is right.I sort of know what you mean about other students. I remember once in undergrad, a roommate and I were having our weekly pizza and beer in the common room. Our other roommate stomped by and, out of blue, pitched a fit about how she wished she were rich and could sit around eating pizza! We thought it was hilarious, though. We referenced it for years. Who can predict other people?Note: she was working her butt off to spend $thousands$ joining a sorority and buying a new car.
From my point of view, sometimes it's a luxury to have the time and resources to cook a proper meal at school, as opposed to having to get take-out or rely on the school's dining services, which are often abysmal.
Freaky, the next time your mom gripes about the price of salad dressing, join right in with her. if she's all bent out of shape because salad dressing is $3.99 a bottle, tell her that at college it's $4.25 a bottle. She tells you milk is $2.99 a gallon? You recently heard that in New York it's $4. As you walk around, every day, just learn the price of one item at random and pull that out of your sleeve if she complains about something.Freaky's Mom: "The salad dressing was $3.99 a bottle!"Freaky: "That's insane! Do they make it with solid gold or something? Why don't they just have the cashiers pull out a handgun at the register and rummage through your wallet?"Freaky's Mom: Freaky: Do you know what CARROTS cost? Carrots! They're like three dollars a pound! And if you want organic--FORGET IT! You'd need a bank loan! The stupid things grow in the dirt, for crying out loud. It's not like they're hand-extruded through a million dollar machine only owned by NASA.Freaky's Mom: Uh...yeah.Freaky: Oh, yeah, I forgot--these pearl earrings just look great on me. Every time I see them in the mirror, I think how awesome they look. But I'd better not wear them to the grocery store or they'll jack up the price on the salad dressing even further! Oh well--gotta practice my clarinet now.Freaky's Mom, thinking: When exactly did I lose control of the conversation?


text: Thanks all! More progress on the dread today this weekend. I'm hoping to finish up the conversion work tonight or saturday one everything except the arms. I'm posting this because I'm not quite sure on the shin armor. Part of me thinks it makes him feel a little too thick around the ankles so I'm asking for opinions before I finish these up and put the cables back into place.


text:
News & Analysis
@rick any guesses, who will replace TI in next generation kindles ?
Nvidia seen leading in tablets, Qualcomm in phones
Rick Merritt
SAN JOSE, Calif. – Revenue for mobile applications processors grew at a whopping 77 percent for tablets and 58 percent for smartphones in the third quarter of 2012, according to reports from Strategy Analytics.
Nvidia held its lead in non-iPad tablets, taking a third of the sector and 17 percent of the overall tablet processor market. Apple still dominates with its A-series chips in 53 percent of all tablets, given the iPad's success.
Overall $900 million in integrated tablet processors sold in the quarter, up 77 percent from the same quarter in 2011, said the market watcher in its tablet report that tracks chips from 13 vendors.
Only one percent of the tablet chips included basebands, limiting design wins for integrated parts from Broadcom, Mediatek and Qualcomm, the market watcher said. Design wins in units such as the Microsoft Surface helped move Nvidia ahead of rivals Texas Instruments, Qualcomm and Samsung.
"Nvidia is well-positioned to maintain its share in non-iPad tablets in the next few quarters," said Sravan Kundojjala, a senior analyst at Strategy Analytics.
Any idea about TI's share in tablet market? Should be pretty high with their socket in the Amazon Kindle devices, which is the only other tablet other than iPad/nexus7 that's selling well.
Interestingly Strategy Analytics did not talk about TI's Omap in tablets. But given TI's move out of the space I would expect it is diminishing and I wonder whether they might have lost the design win for the next gen Kindles.
Robotics Developer
I am wondering if the integrated approach of Qualcomm and Broadcom for the tablets providing baseband support is going to be a significant factor going forward? Is there another feature or limiting factor that is in play? The market share that Apple enjoys has got to be a big fat target for the other players. I wonder what 2013 will hold for new products.
...and Intel once again being non-competitive tablets/mobile in 2013 or 2014. That is the interesting story.
Qualcomm 800 and Tegra 4 much better than Intel just released Clover trail by far. Good thing Intel compared Clover trail to 2011 shipping Tegra 3 last week.
Qualcomm800/Tegra 4 much better than Intel's about a year away release Bay Trail Q4-Q1/14 release (no integrated LTE) but even without integration.... Foundry 28nm HPm / HPL is better than Intel's 22nm.
Time for EE
Just curious why you used an image of the IBM Cell Processor chip to headline an NVidia/Qualcomm story?
It was handy.
You have pretty good eyes (or maybe bad ones) if you can see this is an IBM Cell processor.
True it is not an Nvidia or Qualcomm chip but some other, probably eight-core multiprocessor, I suspect an x86.


text:
HOROSCOPES: Jan. 29
AQUARIUS (Jan. 20-Feb. 19) — An involvement where you share a mutual interest with another should work out quite smoothly today in some dealings you have with a person who is very difficult to please.
PISCES (Feb. 20-March 20) — The timing could be unusually good for you to make a request of someone who doesn't readily grant favors. Point out to this person what would be in it for him or her.
ARIES (March 21-April 19) — By cleaning out the basement, attic or garage, you might discover some gems that you put aside in the past and forgot about. Be sure to open all those old boxes.
TAURUS (April 20-May 20) — A social gathering could pair you with someone whom you've been very eager to approach. Don't be hesitant to introduce the reason why you wanted to get in touch.
GEMINI (May 21-June 20) — Certain financial or commercial matters can be successfully concluded to your satisfaction if you're willing to take the time and effort to do so. Don't coast when you can run.
CANCER (June 21-July 22) — Someone older or more experienced might point out a new direction for you. It could be some of the best advice you've received in a long time.
LEO (July 23-Aug. 22) — You're in a favorable cycle for profiting from situations initiated by someone else. Be on the alert for anything different that sounds enticing.
VIRGO (Aug. 23-Sept. 22) — Even if some of your present expectations seem to be a bit outlandish to some of your friends, they really aren't that far-fetched from your perspective. Your view is clearer than theirs.
LIBRA (Sept. 23-Oct. 23) — Something extremely constructive could develop through the efforts of another, which will give you the assistance you need to get ahead.
SCORPIO (Oct. 24-Nov. 22) — You're likely to get an opportunity to cultivate a new friendship. It might even be with someone whom you've been anxious to get to know better. This could be the start of something beautiful. Continued...
SAGITTARIUS (Nov. 23-Dec. 21) — A little extra effort where your career is concerned could put you out in front of the pack. Be assertive and conscientious when pursuing your objectives.
CAPRICORN (Dec. 22-Jan. 19) — If you allow a past educational experience to guide you, everything should work out quite beautifully in your dealings with someone who is very difficult to please.
See wrong or incorrect information in a story. Tell us here
Local Guide
Business Name
Location, ST | website.com
Social Wire
National Life Videos
- Attorney believes FBI shifting media location a good sign in search for Jimmy Hoffa (4144)
- Mob underboss says Jimmy Hoffa was "buried alive" at dig site in Oakland Township (3270)
- Hoffa mystery wrapped up in Detroit mafia lore (2190)
- POLICE BLOTTER JUNE 18: Apparent suicide committed at home; Woman dies of drug overdose (1669)
- Tucker Cipriano pleads no contest to first-degree murder, will spend life in prison (1492)
- Car rams into Pontiac building to avoid accident WITH VIDEO (1392)
- Residents concerned about Independence Township crosswalk they believe is dangerous; road commission defends system (1130)
- New backcourt leads Lathrup over Dragons (19)
- Mob underboss says Jimmy Hoffa was "buried alive" at dig site in Oakland Township (10)
- 'Anyone can be a father, but few are truly dads'; Oakland Press readers honor their dads this Father's Day (6)
- Jury rules in favor of Gordie Howe in $3 million lawsuit involving destroyed memorabilia (6)
- Macomb coroner accused of running 'tyrannical' regime at morgue (5)
- Appeal filed to split up former Pistons owner Bill Davidson's charitable foundation (5)
Recent Activity on Facebook
Blog Center
Cat Chat
Caren Gittleman likes talking cats. She'll discuss everything about them, from acquiring a cat, differences in breeds, behaviors, health concerns, inside versus outside lifestyles, toys, food, accessories, and sharing cat stories. Share your stories and ask her questions about your favorite feline.
Outdoor Notes
Roger Beukema shares news from Lansing that impacts sportsmen (this means ladies as well) and talks about things he finds when he goes overseas to visit my children, and adding your comments into the mix.
Earth's Almanac
Join Jonathan Schechter as he shares thoughts on our natural world in Oakland County and beyond.


text:
Daniel Martin
Those projects I work in my spare time on. Other things I send to the mailling lists are things I've contact with at work (usually).
xcb - xinput
Highest priority at the moment.
Implementation with XI up to v2.3 is out for reviewing (http://lists.freedesktop.org/archives/xcb/2013-January/008116.html). As much as possible was done. But, it still contains "uninterpreted" stuff, see the ToDos below or the implementations itself.
- xcbgen/c_client.py
<list> with nested field declarations
<switch> with value test <case>
<popcount> on a list (like <sumof>)
<sumof> on fields in a structure in a list
- xorg-integration-tests
- write unit tests
- xcbgen/c_client.py
- I need to fix up my local branch and publish what I did so far:
- working modifiers
- split of input drivers
- ripped to the bones randr
Email: <consume.noise AT SPAMFREE gmail DOT com>
GnuPG: 0xABEC2905 - AB7E 9C6E C3F4 9817 4026 30D4 F898 E1F6 ABEC 2905
- IRC: bartsch (freenode.net)


text:
Viewing groups 1 to 2
National News Group
This is the State Group for Tea Party Patriot members living within the state of Alabama. The Alabama State Coordinator is Michael Power. For information regarding starting a Tea Party group, joining a Tea Party group, posting your Alabama group with TPP, grassroots organization events or locations in Alabama; contact the Alabama State Coordinator: Michael Power by clicking the coordinator link above left, or contact him at email@example.com or call 256-227-2903. Michael is also a member of the TPP \"Champions\" Speakers Group and is available to speak to public, civic, business and political groups about various Tea party related topics. You can see a list of Tea Party Groups listed in Alabama by clicking the \"Groups\" link. You can also see a google map of Alabama with the location of grassroots groups in the state with contact information by going to http://goo.gl/maps/BV3p
Viewing groups 1 to 2


text:
Men's adidas
Knicks Wool Varsity Jacket
Product Information
Your loyalty doesn't end at the buzzer, and the men's adidas Knicks Wool Varsity Jacket shows off bold Knicks style, game day or any other day. The basketball jacket has your favorite team's name on the back, their logo on the chest and an NBA badge on one sleeve. It features a warm wool build with fleece inside the contrast sleeves.
- Side-seam pockets
- Snap-button front
- Large team graphic on back; Team logo on left chest; NBA patch on right sleeve
- Ribbed cuffs and hem
- Wool front and back body; Woven polyester sleeves, lined in cotton-polyester fleece
- Imported


text:
13. | Lebron James | ||
The definition of a coward. Dont pull a lebron james and leave when ur most needed
1. | Lebron James | ||
To bail out on your team when times get tough. This team sucks, i'm going to pull a Lebron James and sign with a different team.
2. | Lebron James | ||
Lebron James come from the Greek words "Le", which mean "to fuck", "Bron" which mean "in the ass" and "Jai-més" which means "and run away like a little bitch because you know you didn't -- and can't -- get the job done" Examples of use:
Delante West: "Hey Lebron! I Lebron James'd your mom last night!!!" Lebron: "Yea, my mom was pissed... but that's OK... Mo Williams finished the job and I'm gonna Lebron James Cleveland next week!" --- Miami Heat Announcer: "Miamiiiii!!! Aaaare you readyyyy to get Lebroned?" |
3. | LeBron James | ||
Time to clean the slate on the LeBron James definition. A pathetic, ego driven traitor and the main villain of the NBA. His departure to the Heat was truly disgraceful to Cleveland. He decided to announce his move in a classless fashion which is a big fuck you, with no proper goodbye to Cleveland. He whines about not winning rings when in reality he wants to play with 2 of his butt buddies. His explanation for all of this was a lie. more...
Queen James' decision to sign with the Heat happened to be planned out since 2008, when his boyfriends, Dwyane Fade and Christy Bosh were on the U.S. team in the Olympics. Turns out LeBron could have gotten a championship with the Cavs, he just decided to quit like a fucking bitch in the playoffs (2009 vs Magic; 2010 vs Celtics.). The 3 lovers decided to join forces today all because they were pulverizing countries who don't give a squirt of piss about basketball. He didn't wake up the morning of his decision day and talk with his mother about it. Your mother would sure as hell not be okay with you blowing up half of a U.S. state to kingdom come including where you live just to get a small piece of plastic around your finger. And thus his lack of backbone and machismo proves himself as not a knight but a knave, not a leader but a follower, not a winner but a loser! And not only that Cleveland and Akron hate him now but so do the other teams, realizing his free agency was a fucking rig. He's never going to be on par with Jordan and Kobe. |
4. | lebron james | ||
see narcissist Guy 1: Lebron James is making his decision during a 1 hour special on ESPN thursday night.
Guy 2: what a prick |
5. | Lebron James | ||
synonymous with bitch or pussy. One who is disloyal and narcissistic. Could not win title in his hometown so he decided to try and buy a championship. Dude dont pull a lebron james and abandon me like that.
6. | Lebron James | ||
To dump your girlfriend that youve been with for years by taking a dump on her chest and leaving her for a younger hotter girl in miami. Guy 1:Yo did you here Ben shit on Karens chest and left her for that Stacy chick from Miami?
Guy 2:Yeah he really gave her the ole' Lebron James |
7. | lebron james | ||
an ovverated piece of shit who doesnt pass the ball who got the 2009 mvp award even though it should have been dwayne wade. lebron james is a cunt


text:
Live Streaming Radar
KOMU's Doppler 8 First Alert Radar provides a realtime radar image for Columbia and mid-Missouri.
Closings and Cancellations
Stay informed of school closings and other event cancellations in mid-Missouri.
KOMU MyWeather
Sign up for weather alerts by email and keep up with the latest weather information.
Mobile Text Alerts
Recieve weather alerts and other important news information on your mobile device.
MoDOT Road Conditions
Stay updated on highway conditions across Missouri before you head out on the road.
Weather IQ Question of the Day
Test your weather knowledge with our online quiz featuring the weather question of the day.
Interactive Radar | Weather Maps |
See an up to date radar map for when and where you need it. |
Local Satellite & Radar Missouri Satellite & Radar Midwest Satellite & Radar |
School Closings | Highway Conditions |
Stay informed of school closings and other event cancellations. | Keep updated on highway conditions across Missouri before you head outside. |


text: The George Harrison Fund for UNICEF and ACUI Campus ChallengeTo raise funds toward its mission of saving children's lives worldwide, the U.S. Fund for UNICEF in 2008 partnered with ACUI and the George Harrison Fund for UNICEF for a fundraising challenge on campuses across America. To date, more than $1 million has been raised through this Challenge. During the 2011-2012 academic year, college students and staff raised over $230,000 for UNICEF. Similar to previous years, fundraising efforts have been matched, dollar for dollar, up to $150,000, by the George Harrison Fund for UNICEF, leading to a total of $380,000 raised this year for UNICEF programs worldwide. We are saddened to share that Ravi Shankar, legendary sitar player and great supporter of UNICEF, passed away on December 11, 2012, at the age of 92. Shankar was the one who first got George Harrison involved with UNICEF. Together they hosted the Concert for Bangladesh, the first ever major music event for a humanitarian cause. To read more about Ravi Shankar's work with UNICEF, please read our UNICEF Field Notes. It's easy to get startedStudents, other faculty, staff and supporters: Register or join your Campus Team. If you think your college has a team, click here to see which teams have registered and then join that team. If you don't see your college, register it. Already registered? Login at top of this page and then click the "Already Registered" button. Make your own webpage, send emails to friends and family to build your team and win the Campus Challenge! UNICEF Campus SpotlightUNICEF Campus Initiative at The Ohio State University held its annual Fast-a-Thon during "Beat Michigan Week" in partnership with the Muslim Student Association, raising awareness and funds for Syria. The Fast-a-Thon was incredibly powerful, and raised $9,017.33 for UNICEF's work in Syria. |


text:
RB boys track and field take third at conference championships
Share on Facebook |
Share on Twitter |
The Bulldogs took third place with 98 points trailing only league champion Glenbard South (201 points) and Illiana Christian (99 points) at the Metro Suburban Conference championships.
Alex Huffhines won the high jump with a leap of 6-3. Mike Hornung snagged second and third in the discus and shot put, respectively. RB's 3200-meter relay team finished second with a state-qualifying time. Sensational freshman Marvin McKenzie won the 400 meter with a time of 51.81 seconds, captured second in the 200 meter at 23:19 and took third in the 100 meter with a time of 11:46.
Reader Comments
0 Comments - Add Your Comment
Note: RBLandmark.com requires you to login with Facebook to comment.


text:
Saturday, January 23, 2010
Sure we can share our plots and characters with friends or meet with our critique group weekly/monthly to hear the good, the bad and the ugly, but when it comes down to the writing of your book, you must go it alone. You must talk to your characters, visualize your settings, work out plot twists and scavenger hunt word choice alone, in your head.
BUT, for many writers, going it alone does not damn them to hermitization (yes, I made that word up because here, alone in my head, I can free-think and choose to decline spellcheck and Webster's.)
Twitter, facebook, the Verla Kay blueboards, Absolute Write, listserves, etc. are wonderful ways to stay in touch with a community of writers, editors, agents and readers. In a public setting, we shout out our status in haiku-like prose, comment or strike the 'like' button to show our support, and e-meet and eventually become virtual friends with people we probably would not have even heard of or, in the case of famous writers/illustrators, editors and agents, had the opportunity to share thoughts, daily happenings, disappointments and joys.
There is one more virtual tool that has added to my village, and if you are not yet employing this tool I suggest you consider it, the Google Group. I'll admit it, I never heard of a Google Group until the amazing Paula Yoo joined my critique group and showed us then technology-challenged writers the virtues of this wonderful communication tool. She showed us that we can hit one button to email each other, and that all those emails would be saved to our Google Group in an orderly fashion (grouped by subject). Also, and most importantly for critiquing, we could post our manuscripts to this private group so we all have the most updated versions, as well as having a free off-site backup for our work. And so was born Kidscribblers.
Kidscribblers: Stephanie Hemphill, Claudia Harrington, me, Kitty 'Mary' Donohoe, Paula Yoo, Joyce Lee Wong.
These days, all of us in Kidscribblers have had life get in the way and critiquing has taken a back seat to each of our personal pursuits, but because of Kidscribblers, our critique group has not disappeared into the ether. The 6 of us are in constant contact with a click of a button. And when we need each other for a critique, we remain a team. A team bonded by love, and by ease of communication.
In August 2008, I went to the SCBWI National Conference in LA. I met a slew of wonderful people. In fact, every time I go to an SCBWI event, especially the 4-day long LA conference, I make new, wonderful friends. But, usually I go home and lose touch with the people I've met. Not this time. I spent a good deal of the conference with 6 women- learning, eating, drinking, and eating some more. If it was any other year, I would have occasionally emailed these women over the next month or two and eventually we would have lost touch. But that year, I told my posse about Google Groups (thanks to Paula!) and so was born RockSugarBeets--named after a couple of yummy restaurants we went to during the conference. I don't think a day goes by that the RockSugarBeets are not in contact. This is not a critique group. There is no stated purpose. RockSugarBeets, along with Kidscribblers, is my village.
RockSugarBeets: Me, Amber Lough, Cindy Pon, Jacqui Robbins, Sara Lewis Holmes, Elise Murphy, Debbie Friedman.
As most of you know, in the Spring of 2009, I joined Ronnie Ann Herman as an Associate Agent at the Herman Agency. At first, I worked like most agents, signing clients and emailing each separately. But, I have this tendency to want to share articles and posts that I find on the Internet and found myself emailing many a group email. So was born The Corkers (which I did not name but my clients named for me). This is NOT a place where any private business is conducted, but The Corkers is a safe, loving village where my clients and I share our thoughts on the biz and on craft.
For many of us, it takes a village to be a writer. But, we must create our own villages. I hope you all find supportive, creative, loving people to surround yourself with.
Here's to all of your publishing dreams coming true in 2010!
19 comments:
- Judy Clemens said...
It is imperative to belong to a village - or more than one. I am very fortunate to be a part of the Corkers, and have found it to be a supportive, loving place! Thanks, Jill (and my fellow Corkers!)
- January 23, 2010 at 1:40 PM
- Sarah Billington said...
I agree wholeheartedly. I used to find it quite lonely, writing as I don't know many others in real life. But then I became a member of the Corkers (and the morning after signing with Jill found my email filled with warm greetings and congratulations from her other clients, it was WONDERFUL) and through Twitter and Facebook have stayed in contact with the other amaze-ible people I have since met at conferences, sharing our triumphs and woes and frustrations about being a writer. My e-village gets it.
Thanks for the post Jill. - January 23, 2010 at 1:50 PM
- Angela said...
Google groups is awesome, and Corkers has made a great place for all of us co-clients to support one another!
- January 23, 2010 at 2:06 PM
- Pat Posner said...
I love being a Corkers villager. Even though my fellow villagers live in different time zones, we are in daily - or nightly - touch.
Hats off to Jill! - January 23, 2010 at 2:22 PM
- Amy Allgeyer Cook said...
I love my villages!!
And I've used Yahoo groups for years. I'm sure it's similar to google groups. My family (all seven siblings) keep in touch this way. :) - January 23, 2010 at 2:40 PM
- cindy said...
we love you jill!
i know for a fact i wouldn't have made it this far if it weren't for all my writing friends who supported me! - January 23, 2010 at 3:21 PM
- J.E. MacLeod said...
I like my writing villages too. Real life people don't often get the quirkiness of the publishing biz.
And being a Corker is made of awesomeness! - January 23, 2010 at 5:43 PM
- Charlie Cohen said...
Really, as a rule, I don't much like people. Or groups (virtual or corporeal). They frighten me. So does dawn. But back to the point: I have to admit that the Corkers have added immeasurably to my life. They're all so upbeat and positive and informative. And SUPPORTIVE. And they're that way no matter what you do: there's no reasoning with these people. So I have to admit, e-groups may be an okay thing after all.
But I'm still scared of dawn. - January 23, 2010 at 6:29 PM
- Amber Lough said...
The RSBs have made my richer than I could have hoped, and love every one of them. ;-)
- January 23, 2010 at 6:41 PM
- Samantha Clark said...
This is great, Jill, kind of like online support groups for our addiction to writing. :) I agree with you that writing can be so solitary, and having other writers to talk to, be in contact with, bounce ideas off and, of course, critique your work, is so so helpful. I belong to a local critique group and a few of our core members also formed an emergency email critique group, and I'm on a number of listservs, but having an online support group of friends and fellow writers would be great. I'm now looking to start one of these.
- January 24, 2010 at 10:11 AM
- deborahfreedman said...
I'm so glad to be part of your village!
- January 24, 2010 at 12:09 PM
- A.L. Sonnichsen said...
Wow, what a great idea to have a google group for clients. I hope if I ever land an agent, they'll have a google group. That would be fun!
- January 24, 2010 at 8:43 PM
- Christina Farley said...
Absolutely. I don't think I'd still be writing if it wasn't for my writing friends. And I definitely wouldn't be as good of a writer. Looks like you had fun.
- January 24, 2010 at 9:20 PM
- Jacqui said...
...kinda feeling like I might burst into song...
Does anyone else think, perhaps, all these great people congregating around Jill might have something to do with, like, the fact that she RULES? - January 25, 2010 at 7:35 AM
- SABELA01 said...
Thanks for sharing this wonderful information.
- January 27, 2010 at 8:44 AM
- Casey McCormick said...
What a great post, Jill. I'm going to have to check out Google Groups now! I didn't know about it. My group uses Ning.
- January 27, 2010 at 1:45 PM
- Christine Danek said...
I do find it lonely sometimes. I really like searching for others that are feeling the same things I am so I don't feel so lonely. Thank you for the information on Google Groups and belonging to a village. I will look into it.
Thanks! - February 2, 2010 at 4:35 AM
- Nishant said...
I used to find it quite lonely, writing as I don't know many others in real life.
Work From Home - February 12, 2010 at 7:53 PM
- Chris said...
Hermitization--so there is a word for it! Sometimes I forget that writer and recluse are not synonyms. Thanks for the reminder to reach out once in a while, to surround ourselves with people who provide love and support.
- February 13, 2010 at 4:24 PM


text:
- September 18, 2013
MB107 Orientation
- 7:00 pm - 8:00 pm - December 6, 2013
MB107 Executive Presentation Day
- 7:30 am - 5:00 pm - February 5, 2014
MB107 Orientation
Palamountain Hall - 7:00 pm - 8:00 pm - April 25, 2014
MB107 Executive Presentation Day
- 7:30 am - 5:00 pm - October 22, 2013
MB107 Dry Run Presentations
- 6:00 pm - 9:00 pm
Hello and welcome to the Department of Management and Business at Skidmore College! Our program is very unique in that we provide a first-rate management and business curriculum in conjunction with Skidmore's quintessential liberal arts tradition. Thus, our majors and minors enjoy the richness of a broad-based, traditional liberal arts education while also being immersed deeply in the functional areas of business such as accounting, marketing, finance, and organizational behavior. We can think of no better educational combination to prepare students for the complex, multidisciplinary challenges facing our societies today. So, please, explore our site to gain a better sense of who we are and what we are about, and feel free to contact us with any questions you may have.
Why Management and Business at Skidmore?
- Small classes
- Committed and distinguished faculty mentors
- A global and multiculturally diverse perspective
- Hands-on experience, case studies, and presentations
- Curricular breadth and depth
- An extraordinary liberal arts environment
- Thesis and honors opportunities
- Meaningful, relevant internships
Video: MB 107 Presentations


text:
- Text Size:
- ASmall Text
- AMedium Text
- ALarge Text
Sweet potato habanero sauce
Like a little sweet with your heat? This New Orleans-made condiment packs plenty of both, along with a heaping helping of savory. It's a perfect accompaniment to smoked meats, soups, stews, your arm... -- Cochon Butcher ($8.50)
Virginia oysters
Yes, Virginia oysters. Under the stewardship of cousins Ryan and Travis Croxton, Rappahannock River Oyster is making a comeback selling the same Chesapeake Bay oysters (Crassostrea virginica) that their great-grandfather did in 1899. They're sweet, salty, full-bodied, and shipped live in the shell for optimum freshness. Don't forget the gloves and oyster knives! -- Rappahannock River oysters (25 for $25)
Chocolate is chocolate is chocolate right? Nope. This isn't one of those weird, sour, bitter artisanal bars that you have to pretend to like while listening to NPR and making kale chips in the oven. They're knee-weakeningly creamy and robust bonbons that'll make you slump to the floor in joy, then crawl back up for another piece. The fact that it's all raw, fair trade, sustainable and organic is just the cherry on top. -- Fine and Raw (8-piece box $28)
Onion jam
The Fabulous Beekman Boys aren't just my friends and neighbors and the winners of the most recent installment of "The Amazing Race," they also sell some darned good onion jam. John Kilmer-Purcell and Brent Ridge raise goats on their upstate New York farm and are constantly on the lookout for ideal accompaniments to their signature Blaak cheese. This combo of local onion, maple syrup and balsamic vinegar brings a wallop of savory umami flavor to any dish, and it's pretty much going to be the lucky recipient's new favorite condiment. -- Beekman 1802 ($12)
Homemade burrata
If you have had burrata before - this one is probably better. If you haven't had burrata before, DiPalo's website says it can be described as "Mozzarella stuffed with cream and strips of 'stracciatella' (stretched curd) giving it an unusually soft texture." It is described by me as gazing directly into the face of the cheese gods and living to tell the tale. -- DiPalo ($8.99)


text:
- Accessories
- Reviews
Rating 5 star : ( 2 ) Total : 2 ReviewsCustomer Reviews
Pros Cons - (1)
- (1)
- (1)
- (1)
Sort by:2 Item(s)
per page- The Best stove I have every had. Review by ariewood
Pros: Easy Setup, Durable, Powerful, Easy to Use, Easy to Clean, Hot Surface
Cons: Heavy
Would you recommend this product to a friend? Definitely yes
- Fantastic Stove Review by Camper Larry
Pros: Great temperature control, Powerful, Compact, Easy To Clean, Easy to Light, Stable
Would you recommend this product to a friend? Definitely yes
Login to add review
Description Have a question about this product? Chat Now!
Have a question about this product? Chat Now!
Outfitters and outdoor enthusiast take notice! This is Camp Chef's biggest, most powerful outdoor appliance, with the convenience of a 3-sided windscreen and two folding shelves, and convenient folding legs. The three 30,000 BTU/hr burners make this stove great for your family or large groups.
- Matchless ignition - NEW!
- 38" x 16.25" cooking surface
- Cooking surface area: 617.5 square inches
- 3 cast aluminum burners
- 90,000 total BTU/hr
- 31" cooking height
- Deluxe folding legs
- Folding side shelves
- 3-sided windscreen
- INCLUDES: Hose & Regulator
- Propane tank NOT included


text:
I'm all about simplifying and automating aspects of my clients' businesses. I take the following steps to create the perfect, unique business solution:
1. Imagine
First we have to imagine. We combine your dream and vision with my knowledge and skills to envision a unique and effective business solution.
2. Design
Second comes the design. With a scope and needs assessment in place, a website design, application map and database and page structure are determined.
3. Code
Coding comes third. The website structure is coded in valid HTML and styled in CSS, the application is scripted in PHP and JavaScript, and the data is stored in MySQL.
4. Test
Lastly we test. Your web application is bug-free by stress testing it in various conditions and environments. Your dream and vision is reviewed and delivered!
Some Of My Work (there is more)
Interesting Reads
How to Simplify Your Website DesignThe simplicity of the design of a website plays an important role in its success. The most important success factor for every website is its ability to offer substantive and qualitative content in the least complicated manner. These days, one finds several websites overflowing with unrelated advertisements and social media widgets, whi...
How to Make an Old Website Get Better Search Engine Rankings
If you have been hit by Google's latest search engine algorithm updates or just would like to get more traffic and organic search visitors, you do not need to re-invent the wheel. Old sites' rankings can easily be increased using some simple tweaks. Updates and publishing are only one aspect of search engine optimization: you need to i...


text:
Links to HEAD: | (view) (download) (as text) (annotate) |
Sticky Revision: |
rewrote these modules to use the WWDBv2 library. rewrote the Authen.pm verify function to (hopefully) be more readable. -sam
changed the name of the "courseEnvironment" field in the ContentGenerator object to "ce", to match the style and conciesness of the existing "r" and new "db" fields. -sam
make answer previews use $displayMode write a template escape for printing $user, $effectiveUser, &c. nicely -sam
Added an informative comment -dennis
- created macros/IO.pl, which is loaded with no opmask by PG.pm. It is a copy of WeBWorK::PG::IO.pm, with some changes to make it work as a macro package. The translator no longer shares IO.pm's functions with the safe compartment. This is a BAD THING, and should be reconsidered when the Translator is revised. - Changed many (but not all) checks for HTML or HTML_tth modes to match /^HTML/ in the macros. - changed &header to &head in Problem.pm - Added problem environment variables for gif2eps and png2eps and modified &dangerousMacros::alias to use them - fixed MOST of the harmless warnings in the system. there's still the "Use of uninitialized value in null operation" warning in template(), tho. Still to come: - make images in PDFs work - fix TTH mode character encodings on mac (maybe) - have logout button invalidate key - Pretty die messages (from outside of the translator) - Feedback - need nice modular way of sending email - Options - email address and password
updated copyright header. -sam
"normalized" files: - (c) header on all files - standard order of preamble lines: 1. (c) header 2. package PACKAGENAME; 3. short summary of the package (pod's NAME section) 4. use - pragmatic modules 5. use - standard perl modules 6. use - CPAN modules 7. use - webwork modules - ALWAYS use strict and use warnings - use "use base" rather than "our @ISA" so now we can be happy. -sam
Added use strict and use warnings, then cleaned up much of the mess that revealed. --Dennis
This commit brings several packages up to date and working. I wish I could be more specific, but it's been a while since I've committed. You'll have to check the CVS diffs for more info. --Dennis
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.
aubreyja at gmail dot com | ViewVC Help |
Powered by ViewVC 1.0.9 |