Существуют ли какие-либо планы по созданию стандарта на основе свободы?
В последние несколько месяцев и, возможно, даже лет, Ubuntu и Canonical часто критиковались за разработку программных и настольных компонентов, не разговаривая с другими группами в сообществе свободного программного обеспечения. Я не хочу комментировать эту тему, но я вижу проблемы, связанные с созданием «проприетарного» решения для отображения индикаторов и progressbars с помощью пусковой установки, такой как Unity.
В мире бесплатных и открытых настольных сред мы часто пытаемся стандартизировать детали и библиотеки или писать спецификации для расширения сотрудничества между различными рабочими столами.
В этом контексте предложение стандарта для этих индикаторов было бы большим шагом на пути к лучшему совместимость между рабочими столами.
Эти индикаторы представляют собой отличную функцию на рабочем столе Linux, и я уверен, что другие проекты, такие как AWN, Docky и т. д., подберут их.
Заранее спасибо, Sebastian Billaudelle
Спасибо вам за то, что вы сделали это в качестве стандарта и поощряете проекты для его реализации.9 ответов
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
-
1Infact Я только что задокументировал протокол DBus для API-интерфейса Launcher здесь wiki.ubuntu.com/Unity/LauncherAPI Это прогресс по крайней мере :-) – kamstrup 14 February 2011 в 17:45
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
Я являюсь злым вдохновителем свободы, когда многие из этих вещей будут реализованы: -)
В стандартах есть неотъемлемые проблемы - а именно, что они являются стандартами :-) Если вы установите их в камень, вы должны придерживаться их, если они будут стоить бумаги, на которой они написаны. Если у вас появятся непредвиденные недостатки или проблемы с дизайном, у вас проблемы. Вы можете либо расширять, либо обнимать его, либо делать что-то совершенно другое. Независимо от того, что вы где-нибудь расцветете для вашего выбора.
Тем не менее, я не думаю, что вы можете найти много, которые возражают против того, что хорошо написанный, продуманный и проверенный стандарт - это хорошая вещь. Проблема в этом.
Для Ubuntu у нас есть очень быстрые циклы для разработки функций, и если мы сначала обсудим стандарт FDO, а после этого реализуем его, у нас просто не будет возможности доставлять функции в темпе, который мы делаем прямо сейчас.
Подход, который мы принимаем сейчас, - это, в основном, попробовать на практике, а затем, если мы будем очень хорошо разбираться в чем-то, мы можем разработать их как стандарты. Но если мы увидим, что мы сами меняем спецификации каждый цикл, это может просто растратить все время, если мы привлечем людей к дискуссиям по стандартизации, не так ли?
Так что в принципе я уверен, что мы согласны :-) Проблема заключается в том, как туда попасть, не подвергая риску пользователя.
Еще один способ взглянуть на это - не обязательно утверждать, что «стандартом» является DBus API или письменная спецификация. Устойчивая библиотека API + ABI так же хороша в моей книге. Тогда стандарт не является читаемыми человеком словами, а машиносчитываемыми двоичными инструкциями.
Извините за длинный ответ, но это сложный вопрос: -)
-
1Infact Я только что задокументировал протокол DBus для API-интерфейса Launcher здесь wiki.ubuntu.com/Unity/LauncherAPI Это прогресс по крайней мере :-) – kamstrup 14 February 2011 в 17:45