Здесь вы можете увидеть:
- общие заметки о жизни;
- найденный мной юмор на просторах интернета и реала;
- копания с Debian/Linux/etc;
- заметки про Финляндию
- и много другой всякой фигни.

Мои жаббер-аккаунты:
основной:
jackyf[dot]devel{at}gmail[dot]com
вспомогательные:
jackyf{at}jabber[dot]kiev[dot]ua
jackyf{at}jabber[dot]ru

Умейте ценить каждый день.

Лоймаа - город в западной Финляндии с населением в ~16 тысяч жителей.



( другие фотографии )

К рекламе в целом я отношусь негативно. Реклама подрывает конкуренцию, неявно стимулируя людей покупать не то, что человек выбрал, а то, что человек видел.

Большинство рекламных роликов довольно уныло: искусственные ситуации, неправдоподобные диалоги, неестественно счастливые люди, мужественный закадровый голос.

Однако, если подойти к вопросу с огоньком, то можно создать то, что хочется пересматривать ещё и ещё. Наслаждайтесь.

Half a year since the last status update, so here we go:

• New mailing lists: cupt-user and cupt-devel, thanks to the Alioth people&infrastructure. The first, cupt-user is the preferred form of the feedback (except of the bug reports, which still go to the Debian BTS) from now on, also I intend send there announcements and questions to all users who care. The second, cupt-devel, is set as maintainer address for the Cupt package in Debian; also, as the name suggests, a place for discussions about the code if any.


• New versions: 2.3, 2.4 and 2.5 have been released bringing many new command line switches, an opt-in ANSI color support for the action preview prompt, improvements in the error and warning messages and more.


• Multiarch: Cupt in wheezy won't support multiarch. No standard is published yet and not enough time to test for a stable release. Once the standard is published, I plan (but don't promise) to set the branch in the repository and evaluate the implementation details.


• Localizations: the code and message strings seem now ready, and I'm going to send a call for translations in a week.

Не смог найти первоисточник, но фраза очень остра:

"When people ask me 'plz' because it's shorter than 'please' I tell them 'no' because it's shorter than 'yes"

Конечно, всё хорошо в меру. Я предпочту 'IIRC' фразе 'if I remember correctly' в кругу работников отрасли информационных технологий. Для человека, с которым я не знаком, я, пожалуй, употреблю полный вариант.

Suppose that you need to write an interface to a function which draws triangles. It could look like this: (the language is a C++-based pseudocode)

void rawDrawTriangle(size_t a, size_t b, size_t c) { ... }
bool isValidTriangle(size_t a, size_t b, size_t c)
{
  return (a + b > c) && (a + c > b) && (b + c > a);
}

void drawTriangle(size_t a, size_t b, size_t c)
{
  if (max(a, b, c) > MAX_LINE_LENGTH)
  {
    throw("one of sides is too big");
  }
  if (!isValidTriangle(a, b, c))
  {
    throw("invalid triangle");
  }
  rawDrawTriangle(a, b, c);
}

void userFunction()
{
  ...
  drawTriangle(3, 5, 7);
  ...
}

And the following is how a bureaucratic version of the code could look like:

class Certificate
{
  time_t getCreationTime() const { ... }
  Certificate() { ... }
};

class TriangleIsValidCertificate: public Certificate
{
 public:
  const size_t a;
  const size_t b;
  const size_t c;
 private:
  TriangleIsValidCertificate(size_t a, size_t b, size_t c) { ... }
 friend class TriangleCertificationAuthority;
};

class TriangleCertificationAuthority
{
  static TriangleIsValidCertificate getTriangleIsValidCertificate(size_t a, size_t b, size_t c)
  {
    msleep(random() * 2);
    if ((a + b > c) && (a + c > b) && (b + c > a))
    {
      if (a == b && a == c)
      {
        msleep(random() * 10); // hm, suspicious query
      }
      return TriangleIsValidCertificate(a, b, c);
    }
    else
    {
      throw("invalid triangle");
    }
  }
};

class LineIsDrawableCertificate: public Certificate
{
 public:
  const size_t length;
 private:
  LineIsDrawableCertificate(size_t l) { ... }
 friend class LineCertificationAuthority;
};

class LineCertificationAuthority
{
  static LineIsDrawableCertificate getLineIsDrawableCertificate(size_t length)
  {
    msleep(rand());
    if (length <= MAX_LINE_LENGTH)
    {
      return LineIsDrawableCertificate(length);
    }
    else
    {
      throw("the line is too long");
    }
  }
};

void drawTriangle(size_t a, size_t b, size_t c, LineIsDrawableCertificate lineCerts[3], TriangleIsValidCertificate tivCert)
{
  msleep(rand() * 5);
  if (lineCerts[0].length != a || lineCerts[1].length != b || lineCerts[2].length != c)
  {
    throw("your application is rejected");
  }
  if (tivCert.a != a || tivCert.b != b || tivCert.c != c)
  {
    throw("your application is rejected");
  }
  if (time() - tivCert.getCreationTime() > '60 milliseconds')
  {
    throw("your application is rejected");
  }
  msleep(rand());
  rawDrawTriangle(a, b, c);
}

void userFunction()
{
  ...
  size_t a = 3, b = 5, c = 7;
  auto aCert = LineCertificationAuthority::getLineIsDrawableCertificate(a);
  auto bCert = LineCertificationAuthority::getLineIsDrawableCertificate(b);
  auto cCert = LineCertificationAuthority::getLineIsDrawableCertificate(c);
  auto tviCert = TriangleCertificationAuthority::getTriangleIsValidCertificate(a, b, c);
  drawTriangle(a, b, c, array(aCert, bCert, cCert), tviCert);
  ...
}

I experienced situations of writing substantial amounts of code (feature branches) for hours, days and even weeks only to find later that the written code can be thrown to the bin, either because of hidden design problem(s) or too much negative implications outweighting the positive implications of the change.

After reading some recent multiarch threads on debian-devel@ and seeing what hacks are seriously being proposed to implement only to keep the thing going, I now think that the low-level part of the Debian multiarch implementation proposal is no less broken than its high-level part, and the whole proposal is a one big hack which requires and will require more subhacks. Some will benefit from the added functionality, but all, both maintainers and users will suffer from drawbacks.

How two paragraphs above are related? We still have the time to revert the changes and say "sorry, it was a nice idea but the software world isn't ready".

Первая крупная вылазка зимой, первая не в областной центр, и первая не с помощью железнодорожного транспорта.



( Read more... )

В новом две тысячи двенадцатом году хочу пожелать этому миру больше тех редких людей, которые умеют сеять счастье вокруг себя.

It took longer than usual, but I believe it's worth.

I just released Cupt 2.2.0~rc1 to Debian experimental. To experimental, because there are important changes and I would appreciate "in-field" testing before final 2.2.0.

Here are the major changes since 2.1.x:

• Dpkg action sequencer improvements. There are multiple improvements, both in quality and speed.


• Repository index deltas. Or, in APT terminology, "PDiffs". Finally, there is an initial support for them. They are switched on by default (if you have Recommends disabled, make sure you have 'ed' package installed). To switch off, set the option 'cupt::update::use-index-diffs' to 'no'.


• Action override options. New console front-end's options '--install', '--remove', '--purge', '--satisfy', '--unsatisfy' allow to mix any of corresponding actions to the single command. See the tutorial and the man page for examples and details.


• Logging. By default, system changes are now logged to /var/log/cupt.log. Refer to the tutorial section 'Logging' for tuning.

Enjoy and send the bug reports.