Сергей: если у них задолженность за полгода - им только сервиса, на хрен отрубающего всю работу, для полного счастья не хватает.
Я пытаюсь представить, как выглядит ваше предложение с точки зрения клиента, который его обдумывает. Я бы - просто отказался. И даже не потому, что предполагаю динамить оплату сервиса или жду от него подлянок. Просто случаи бывают разные, и глупо совать голову в петлю без всякой на то необходимости. It smells, компрене-ву?
Вообще-то в любой версии будет работать floor( $a / $b ), зачем лишние сущности?
Вот эта "своя реализация", например, может ненароком поймать ошибку точности и выдать 0.999999999999999
Сергей: однако на практике мне схема "оплатил сервис - есть обслуживание, не оплатил - нет обслуживания" представляется более естественной, чем "не оплатил - вообще работать не сможешь".
Это нужно быть сильно недальновидным или очень доверять контрагенту, чтобы под такое подписываться. Даже предполагая всеобщую добрую волю и никаких подвохов.
Сергей: не так же.
У них есть альтернатива и есть гарантия, что завтра они не пропадут с концами.
В вашем же случае в любой момент может оказаться, что вы загремели в больничку на Самуи без интернета, а у клиента встал колом весь офис, и никто не может исправить эту ситуацию за разумные деньги.
Сергей: я, конечно, не знаю вашей ситуации. Но связываться с обслуживателем, который сразу монтирует рубильник и обещает за него дернуть, как только ему что-то не понравится, я бы не стал. Да и фактор автобуса маловат...
Сергей: просто если ваша услуга - не столько система, сколько обслуживание, имеет смысл и говорить об оплате обслуживания, а не системы. То есть отталкиваться от ваших часов возни с проблемами, а не от количества установок. Возможно, корреляция будет прямой, но контролировать время с вашей стороны куда как проще.
Вопрос в том, чем ваша "сборка" отличается от любого бесплатного дистрибутива.
Очевидно, какие бы то ни было ограничения могут быть только в рамках этих отличий.
Вот кто вам это сказал? Лично Гейтс?
Нужен вам гуй в Убунте - apt-get *-desktop, и не делайте людям голову.
Впрочем, если вы по-прежнему верите, что вам зачем-то необходимы окошки, ниже уже ответили - удаленное подключение работает без проблем.
Скорее всего, это будет быстрее, чем Шторм в виртуалке.
Не так быстро, впрочем, как при выкидывании винды из этой схемы вовсе.
GrAl: и не будет без опыта. Представьте, что ООП - единственный инструмент, который у вас есть. И все должно решаться только с его помощью. Так придет понимание, как сделать что-то удобнее с ООП, а потом - и как именно ООП позволит сделать все удобнее и проще.
Главное - быстрее перейти от "запихну процедуры в комок и назову это классом" к "вот эта часть кода пересекается с другими только вызовом нескольких методов и представляет собой абстракцию более высокого уровня, чем просто набор методов".
Не могу, правда, сказать, насколько для этого подходят именно выбранные вами языки.
Anonymous: И что теперь происходит с ней при изменении размеров окна браузера?
Я ни разу не верстак, но такие вещи вроде бы сто лет как делаются width: 100%; padding-left: /*ширина фиксированной колонки плюс отступ от нее*/
Дмитрий Александров: ну да, классический рецепт многомиллионного контракта: возьмите начальника, полномочия которого превышают компетентность, и уговорите его потратить любые деньги, лишь бы снять с себя ответственность. Особенно хорошо рецепт работает в бюджетных учреждениях.
В Linux в принципе не требуется "редактор с возможностью FTP-соединения".
Система сама обеспечивает такое соединение прозрачно для любых программ.
Лучше, конечно, не FTP, а SFTP.
Я пытаюсь представить, как выглядит ваше предложение с точки зрения клиента, который его обдумывает. Я бы - просто отказался. И даже не потому, что предполагаю динамить оплату сервиса или жду от него подлянок. Просто случаи бывают разные, и глупо совать голову в петлю без всякой на то необходимости. It smells, компрене-ву?